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FRIS PROJECT EXECUTIVE SUMMARY 


The Forest Resource Information System Project (FRIS) was a coopera- 
tive effort between the National Aeronautics and Space Administration 
(NASA) and St. Regis Paper Co, Purdue University’s Laboratory for 
Applications of Remote Sensing (LARS), under contract to NASA, supplied 
technical support to the project. 

$ 

FIRS was an Applications Pilot Test (APT) Project funded by NASA. 

The project was Interdisciplinary In nature Involving expertise from 

both the public and private sectors. FRIS also represented the first f 

APT to Involve a large broad base forest Industry In a cooperative with 

the government and the academic communities. 

Purpose 

The goal of FRIS v;as to demonstrate the feasibility of using com- 
puter-aided analysis techniques applied of Landsat Multlspectral Scanner 
Data to broaden and Improve the existing St. Regis forest data base, 
thereby creating the foundation of a dynamic lnform<!‘tlon system. The 
successful demonstration of this technology during the first half of 
the project led to the establishment by St. Regis of an Independently 
controlled operational forest resource Information system in which 
Landsat data makes a significant contribution. FRIS can be %'lewsd by 
the user community as a model of NASA's Involvement In practical appli- 
cation and effective use of space technology. Additionally, FRIS 
served to demonstrate the capability of Landsat MSS data and machine- 
assisted analysis technology to private industry by: 

0 Determining economic potentials, 

0 Providing visibility and documentation, and 

0 The ability to provide timely Information and thus 
serve management needs. 

The ultimate long tem successfulness of FRIS will be measured through 
future development of remote sensing technology within the forest pro- 
ducts industry. 

Scope ^ 

FRIS was funded as a modular of phased project. The original ^ 

project concepts were developed In 1973, and a formal project plan was 
submitted to NASA in 1976. The project officially began in October 1977 
after the signing of a cooperative agreement between NASA and St. Regis; 
and after the completion of contractual artrangements with Purdue Univer- 
sity. The project officially ended In May 1981. 
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Summary 

In retrospect, the FRIS project addressed more than the demon- 
stration and implementation of remote sensing technology in an opera- 
tional Industrial forestry environment. Conceptually, the FRIS project 
dealt with the entire range of activities which are required for inten- 
sive forest management. The success of FRIS depends on its ability to 
Intergrate and manipulate digital inventory data, maps, and land cover 
to provide information to serve management needs. Key to meeting these 
requirements is the geographic Inform^itlon system acquired by St. Regis. 

Contractually, LARS provided remote sensing support for FRIS, The 
remote sensing elements of the project wore basically; a) a proof-of- 
concept, and b) the transfer and implementation of system capabilities 
to St. Regis. The demonstration phase of the FRIS project proved the 
concept that computer-aided analysis of Landsat MSS data could effectively 
be used to delineate, map, and monitor the southeastern forest resources. 
Based on encouraging demonstration results, the decision was made by 
St. Regis management to pursue the System Transfer portion of the pro- 
ject. This report addresses those activities. 

The most significant aspect of the transfer and implementation of 
the image processing technology to St. Regis was the level of commit- 
ment of the user. Without the dedicated efforts of the St. Regis staff 
and support of their management, FRIS would have been just another tech- 
nology evaluation project. In the future, FRIS may be looked back on as 
a pioneering effort which fostered the application of remote sensing 
technology in forestry. For the present, FRIS is an example of how roan's 
imagination and Ingenuity help him do his job. 

Key accomplishments of the FRIS project were; 

0 Satellite acquired data provides Important information for 
forest management. 

0 Effective use of satellite acquired data requires that it be 
combined with other data sources. This combination is most 
efficiently done with an automated mapping system. 

0 FRIS represents a multi-functional information system wherein 
the Independent functions of imagery, mapping, and Inventory 
are brought together to form an Integrated digital data base. 

0 The FRIS data base provides management with an accessible and 
retrievable Information sources in a timely and efficient manner. 
Furthermore, this data base is totally responsive to changes 
and modifications to the data as they occur. 
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1,0 INTRODUCTION 


Tho third phase of the Forest Resource Information System Applica- 
tion Pilot Test designated as the System Transfer Phase» was designed to 
transfer remote sensing technology to St* Regis, The third phase spanned 
an 21-month period and Involved the definition* transfer and preliminary 
implementation of an image processing capability at St, Regis. 

The system definition activity began during Phase II with the 
Identification of user's needs in terms of remote sensing inputs. These 
needs were transformed into system performance requirements and a list of 
functional specifications. Once these specifications were defined, avail- 
able software and hardware systems were evaluated in terms of their suit- 
ability for FRIS, 

A more complex task undertaken during Phase III involved technology 
transfer. These activities were directed at providing St, Regis personnel 
with the capabilities to understand, analyze and interpret remote sensing 
data. Since an Important aspect of the project goal was to provide 
St. Regis with an independent capability to utilize the technology, this 
aspect of Phase III was critical to the ultimate success of FRIS. 

The last major emphasis of Phase III related to the implementation 
and documentation^ of image processing software transferred to St. Regis. 
Since St, Regis decided to Implement the LARSES version 3.1 software, a 
major effort was mounted to upgrade this software. The modified software 
package is called LARSFRIS and includes the basic elements of LARSYS 
version 3.1 plus some of the new software that was included in develop- 
mental LARSYS or LARSYSDV. Another major activity associated with up- 
grading the software was an upgrade of the software documentation for 
Inclusion in COSMIC. 

Details regarding these activities and other tasks conducted during 
Phase III are reported in the sections which follow. 
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2.0 SYSTi;.J TRANSFER ACTIVITIES 


The Forest Resource Information System consists of a forest inventory 
or tabular componentu a graphics component and an image processing com- 
ponent. The primary emphasis of tARS staff involved with the project 
was directed toward the image processing portion of FRIS> figure 2.1. 

System transfer activities, therefore, consisted of transferring software . 

and capabilities to St. Regis. 

Software transferred to St. Regis Included data preparation, or * 

preprocessing software, and data classification software. The basis for 
the data classification software was LARSYS version 3.1| and developmental 
LARSYS or LARSYSDV. These elements combined form L^SFRIS. 

Capability or the capacity to optimally utilize this software was 
more difficult to transfer. Therefore, various technology transfer 
activities were conducted for St. Regis to build their capability. 

Ultimately, the most effective transfer of technology occurred when 
St. Regis hired two LARS staff as permanent FRIS employees. 

The system transfer activity was dedicated to the physical transfer, 
implementation, and testing of software that was transferred to St. Regis. 

The software which was transferred related specifically to those routines 
required to prepare the Landsat digital date for analysis and those 
routines used to classify and display the data. These comprise respect- 
fully the Preprocessing software and the LARSYS software. These elements 
form the FRIS Image Processing Subsystem. 

A subgroup of the Preliminary System Design Committee, which was 
created during Phase IX', was responsible for the software transfer and 
installation task. The subgroup was comprised of personnel from both 
St. Regis and LARS. This group met in mld-du].y, 1979 to outline the plan 
for transfer and installation of software. Highlights of their plan are 
presented below: 

0 LARSYS version 3.1 and LARSYSDV will be the foundation for 
the FRIS image processing subsystem. 

0 LARS data preparation software will be the nucleus of the FRIS ' 

preprocessing software. 

0 Software will be Installed at the St. Regis National Computer 
Center (NCC) in Dallas, Texas. 

0 The software will operate in batch mode on an IBM 3033, or 
similar computer. 

0 User Interface will be provided via ROSCOE. 


FOREST RESOURCE INFORMATION SYSTEM 
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proposed structure for FRIS consisting of three independent subsystems. 



0 The Landsat CCX data and permanent Intermediate files will be 
maintained on tape. 

0 Temporary files will be kept on disk. 

0 Documentation consisting of User’s Manuals, System's Manuals, 
and Program Abstracts will be provided to St. Regis. This 
documentation will be included in the public domain via 
COSMIC, 

A listing of the LARSYS, LARSYSDV and preprocessing software that 
was transferred appears in Appendix A. Responsibility for implementation 
of this softv/are on the St. Regis computer rested with St. Regis personnel. 
LARS staff provided program tapes, listings and documentation. They also 
acted as consultants during the software installation, providing assistance 
when needed. 

As an aid to LARS staff during the system implementation activity a 
remote terminal link to NCC was provided by St. Regis. The terminal, 
an IBM 3275, operated under ROSCOE protocol, thereby allowing LARS to 
emulate a St. Regis remote site. Computer output was acquired through 
a Data 100 printer, The printer operated as a remote job entry terminal 
and was connected to NCC via a dial-up modem. Support for the RJE 
station was provided through the FRIS contract. 

The System Design Team had the remote hardware to NCC functional £it 
LARS in November, 1979. Once the hardware was operational a ROSCOE 
training session was held at LARS to train FRIS personnel. At the com- 
pletion of these activities, which closely coincide with the Initial 
installation of software at NCC, the system transfer activities proceeded. 

The LARS/NCC terminal connection was designed to; 

0 Assist St. Regis staff in debugging the NCC Installation of 
LARSYS and LARSYSDV software. 

0 Suggest program updates or modifications to St. Regis staff based 
on ROSCOE remote batch operations on a NCC computer. 

0 Develop user documentation for batch Preprocessing and LARSYS 
operations initiated from a remote terminal via ROSCOE. 

0 Develop user training sessions for St. Regis analysts in the use 
of the St. Regis/lARSFRIS software. 

0 Develop analyst aids. 

Remote terminal operations between LARS and Jacksonville were main- 
tained during this period to provide for continuing analyst training 
of St. Regis staff. ^Then the preprocessing and LARSYS software were 
tested and considered "operational” at NCC the LARS/JAX terminal link 
was disconnected. 



2.1 System Design Task 


System design activities began during Phase II with the Identification 
of system requirements and constraints. Preliminary design requirements 
were focused on: 

0 Communications - movement of data and Information between computing 
sites. 

o Resources - Identification of system component requirements In 
terms of; a) hardware, b) softvjare, and c) man power* 

0 Costs - financial requirements necessary for system start-up and 
operations. 

0 Documentation - level of system and user explanation necessary to 
operate the system. 

0 Transferability - the ease, or difficulty, of Implementing any 
software module that Is an Intergral part of the system. 

0 Languages - refers to software programming language. 

0 Interface = describes how the user would access and manipulate 
the system. 

The constraints that were considered In developing the preliminary 
system design were: 

0 The system that was to be Implemented would be specifically 
tailored to the St. Regis application. 

0 The system v/ould be operational, that Is, St. Regis would have 
an Independent remote sensing data analysis capability at the 
end of the Application Pilot Test. 

0 The remote sensing components of PRIS (both hardware and software) 
would have to be attractive In terms of cost to St. Regis 
management, l.e.: 

a. reasonable start-up and operating costs, 

b. relatively quick (aim for , 5 -year) pay-back period, 

c. potential cost-efflclencias or cost reductions or cost 
avoidance associated with the system, <md 

d. require a minimum of new human resources* 

0 The system designed should utilize existing and computational 

resources where feasible. ''I 
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0 The system should be easy to implement. 

0 The quality of information from the system should be compatible 
to or better than currently available. 

A plan for implementing these concepts was developed during the latter 
stages of Phase II, This plan became the focus of the system transfer 
activities of Phase III. 

* 

Between the sixth and ninth months of Phase II the System Design 
Committee met several times to formalize FRIS specifications. The list 
of functional specifications that were developed by the committee appear « 

in Table 2.2.1. Three vendors of data base systems were asked to demon- 
strate their systems capabilities and bid on the system Installation in 
Jacksonville, Florida. 

Demonstration materials were prepared by FRIS staff. Each vendor 
received the following data: 

1. Map of All's (Administrative Units) 264, 267, 268, and 271. 

2. Documentation of map contents. 

3. Tape containing digitized map information. 

4. Documentation of digitized tape format and contents. 

5. Tape containing Landsat classification data. 

6. Documentation of classification tape format and contents. 

The requirements for manipulation of these data sets are defined in 
Table 2.2.2. Each vendor was asked to demonstrate their capability in 
these nine areas, or to indicate how they would meet these requirements if 
the capability did not exist. In addition to demonstrating their systems 
capabilities, vendors were asked to provide a firm bid for Installation of 
the System in Jacksonville. 

During the final System Design Committee meeting in Dallas, Texas in 
early December 1979, vendors capabilities were evaluated. The committee 
was primarily concerned with the vendors capability of meeting the FRIS * 

system requirements. Bid Information was used by St. Regis Staff to 

prepare financial evaluation for St. Regis management. ^ 

2.2 Image Processing Transfer 

The core of the FRIS image processing systems consists of modifications 
to the LARSYS software package. LARSYS is a well documented system designed 
to process digital multispectral scanner data. The system currently 
operates on an IBM 370/148 in a virtual machine environment. The software 
transferred to St, Regis did not Include the entire LARSYS package. Further- 
more, it operates on an IBM 3033, or the equivalent, and job Inltlatien is 
through remote job entry stations. 
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Table 2. 


I 




2tl Funcclonai Specifications for Evaluation of FRIS System Design 
Alternatives 

1, Graphic Data Capability 

A. Input 
D. Analysis 
G. Update 
D. Output 

II. Tabular Data Capability 

A. Input 

B. Analysis 

C. Update 

D. Output 

III. Image Data Capability 

A. Conversion from vector to grid 

B. Conversion from grid to vector 

IV. Other 

A. Hardware 

1. Configuration 

2. Dellverabllity 

3. Support 

4. Data Communications 

B, Software 

1. Availability/cost of source 

2. Support 

3. Transportability 

C. Implementation 

1. Cost 

2 , Time 

D, Vendor Profile 

1. Customer base 

2. Customer Service 

3. Expertise in forest based applications 

4. Vendor Stability 

V. Overall Cost 
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Tabic 2,2.2 FRIS data base manipulation requirements 

1. Produce a plot op the dlgltl,:cd data, containing the AU (Administra- 
tive Unit) and OA (Operating Area.) boundaries for all four of the 
AU’s. 

2. The fourth file of the tape contains some extraneous points, produce 
a clean plot demonstrating the cdlttlng capabilities. 

3. Convert the Landsat classification data from grid to vector format, 

4. Produce a plot of each layer of information 

a. AU boundaries 

b. OA boundaries 

c. Landsat classification 

5. Associate attribute data with each layer of Information 

a. for the AU boundaries layer, the attributes would consist of the 
AU numbers (264, 267, 268, and 271). 

b. for the OA boundaries layer, the attributes of Interest would be 
the OA numbers, the forest type, and the age of the stand (this 
information may be found on the sheets describing each individual 
AU). 

c. for the classification data, this would be the names of the classes 
taken from the classification results tape. 

6. Produce an overlay of the three layers of Information. 

7 . Graphically represent where the Landsat classification and the map are 
in disagreement for a cover type, l^hat we have in mind is a map 
depicting areas that would satisfy such Boolean combinations as: 

NONSTOCK (from the Landsat classification) .AND. .NOT. (forest types 

9 .OR. 92 (from the map)). 

8. It would also be desirous to have maps of areas based upon the attributes 
of the OA*s (e.g., Forest types 2, 11, and 2l which are greater than 

15 years old) . 

9. Demonstrate the capability to apply transformations to the vector 
data sets (e.g., for rotation and scale). 
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The major requirements of this task were the modification of the 
existing software to run on a batch machine. St. Regis staff were 
responsible for this implementation, and LARS personnel provided guidance 
and consultation when needed. A list of functions and subroutines that 
were transferred are Included as Appendix A of this report. 

LARSYS version 3.1 as it currently exists at Purdue University's 
Laboratory for Applications of Remote Sensing (LARS), consists of 41 
, processing functions contained in 377 FORTRAN routines and 49 IBM ASSEMBLER 

routines. LARSYS is not just an Integrated set of computer programs 
designed for the analysis of remote sensing data. It is an entire approach 
t to the conversion of remote sensing data into information useful for 

monitoring and inventorying earth resources. Results of the Demonstration 
Phase of FRIS document the utility of the approach to industrial forest 
management in the southeast. 

The System Transfer Phase of FRIS therefore not only dealt with the 
implementation of the LARSYS software, but also the transfer of the con- 
cept. The FRIS image processing subsystem is comprised of a subset of the 
LARSYS version 3.1 software package which are currently available through 
COSMIC. In addition select developmental and experimental routines, some 
of which were developed specifically for FRIS, have also been transferred. 

As part of this transfer activity, source tapes, program listings, 
users' manuals, system manual, control card references, and program ab- 
stracts were provided to St* Regis for 23 image processing processors. The 
following is a brief description of these processors; 

PICTUREPRINT - histograms and displays data in picture form on a 
line printer for each channel selected. 

CLUSTER - using reflectance values from selected channels, groups 
data into classes and displays the results on a line printer. 

STATISTICS - calculates transformed divergence between all class 
pairs and performs these calculations for every set of channels 
requested. 

CLASSIFYPOINTS - assigns each pixel in the data to a class, using 
either the maximum likelihood algorithm or minimum distance rule. 

* The results are written to tape or disk. 

PRINIRESULTS - using the classification results located on tape or 
disk, prints a map and tabulates the number of pixels classified 
into each class. 

IDPRINT - prints most of the information contained in the MSS data 
header record . 

DUPLICATERUN - duplicates a data run from tape to tape, and optionally 
allows arithmetic expressions to be applied to the data. 


xo 


COPYRESULTS - copies classification results from disk or tape to 
another tape. 

LISTRESULTS - prints information located In the header records of 
the classification results. 

PUNCHSTATISTICS - punches a copy of the statistics deck located on 
a classification results tape. 

LINEGRAPH - graphs a line of MSS data on a line printer. 

COLUMNGRAPH - graphs a column of MSS data on a line printer. 

HISTOGRAM - histograms data and produces a deck of the histogram 
information. 

GRAPHHISTOGRAM - on a line printer, displays the histogram produced 
by PICTUREPRINT or HISTOGRAM processors. 

SECHO - extracts and classifies homogeneous objects as if they were 
single pixels. 

MERGESTATISTICS - combines more than one statistics deck into a 
single deck. 

RATIOMEANS - using the mean vectors of classes In a statistics deck, 
calculates and prints the ratio of the values for the specified 
channels and the sum for each class. 

BIPLOT - produces a bispectral piot of classes contained in a 
statistics deck. 

COMPARERESULTS - compares two classifications results over the same 
area for purposes of identifying changes. 

The above processors represent approximately 42,000 lines of FORTRAN, 

5,000 lines of Assembler, and 1,500 lines of CMS (Gambridge Management 
System) EXEC language. The programs were transferred in card Image format 
on 9-track computer compatible tapers. Copies of tape listings and user 
documentation were also provided. 

The task faced by St. Regis personnel was to convert the software 
which ran on an IBM 3031 operation under VM to an IBM 3033 operating under 
>IVS. That is the LARS computer operates as a virtual machine while the 
St. Regis computer operates as a Wtch machine. This meant that the 
LARSYS version 3.1 programs were not directly compatible between the LARS 
and St. Regis IBM machines. The following changes were required in order 
for the software to be compatible on the NCC machine? 

A. Add the function COPYTAP, this allows the data to be read from 
tape to disk and stored on disk. St. Regis has a disk based 
system while LARS is tape based. 


11 


B. Replace conmand language wleli ROSCOB, Due to the operation 
system differences between the two machines, the command language 
had to be modified. ROSCOE is a software package that permits 
St. Regis users to initiate jobs from remote sites. This will 
replace the CMS software which is currently used in LARSYS to 
perform similar functions. 

C. LARSYS contains some bookkeeping routines that were deleted 
because these functions were already handled by St. Regis. 

D. All non-standard file handling routines in LARSYS were replaced 
to meet St. Regis computer software conventions. 

E. All tape handling routines were modified to deal with disks. 

F. Machine dependent assembler language routines were eliminated 
where feasible. 


In order to implement the software at NCC, St. Regis staff had to 
accomplish the following tasks: 



1. 

Compile programs from tape. 


2. 

Create disk files. 


3. 

Modify software for compatibility to St. Regis machine, including 
elimination of bookkeeping, assembler routines and modification 
to tape callable routines. 


4. 

Create ROSCOE modules. 


5. 

Develop links to CIS. 


6. 

Develop St. Regis/LARS user documentation. 

\ 

LARS staff were available for consultation and debugging when needed. 
Our experience during the software implementation was that very little 
assistance was requested by St. Regis personnel. Implementation of these 
software progressed with very few problems. This was most likely due to; 
a) the level of documentation provided with the LARSYS software, and b) 
the knowledge of the staff involved with the implementation. 


2. 

2.1 Programming Additions 


The LARSYS software packages were originally designed to process 
digital multispectral scanner data in a research environment. Periodically, 
modifications and embellishments have been added to LARSYS version 3.1 
support packages to Improve interaction with the huiiian component of the 
analysis activity. Since FRlS is a user oriented, operational system there 
were certain additions to the LARSYS version 3.1 software since the midpoint 
of Phase II. The two newest additions reported this quarter are significant 
because they directly affect FRIS requirements. The two new program addi- 
tions are SMOOTHRESULTS and COMPARERESULTS . 
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SMOOTHRESULTS is a post classification processor designed to emulate 
the human action of creating a mapping cell. Mapping cells are the basic 
component of timber typo or operating area maps. The theory behind the 
mapping cell is simply that areas less than a mlniraura sl?,e, say five 
acres, are ignored for map generation purposes and included as part of a 
larger population, Therefore, a two or three acre inclusion in a type 
would be ignored when the map is created. 

The human quickly handles these small inclusions when making a type 
map. A Landsat classification, however, will display most inclusions that 
fall within the scanner resolution. These will result in a salt and pepper 
effect on classification output. A situation that may accurately protray 
the cover composition but which is often not appealing to land managers 
who are used to working with "clean" (no salt and pepper) maps. 

SMOOTHRESULTS allows the analyst to define a mapping unit and produce 
a class if lea tlon results map which does not exhibit a salt and pepper 
pattern. The processor scans a LARSVS Classification Results File and re- 
places groups of classified points (cells) with the dominant class from 
that group. The analyst has the option to specify the size of the cell 
(CELLSIZE card), class numbers which are to be replaced (PRIORITY card) 
and weighting factors for each class (WEIGHTS card). The output from this 
function Is to tape to disk in LARSYS Glassification Results File format. 
Figure 2.2.1 is an example of a classification result which shows output 
both before and after use of the SMOOTHRESULTS processor. 

An additional option to SMOOTHRESULTS allows the analyst to define 
new classes which are mixtures of old classes wap developed and trans- 
ferred to St. Regis. The control card reference file and program ab- 
stracts are included in Appendix B. 
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The ohhar processor that was upgraded for addition to the FRIS pack~ 
age of software and tronsferred to St« Regis was CC^ARERESULTS • C01IPAR£~ 
RESULTS is a post classification processor, ond is designed to make com- 
parlsons between classification results. This processor is Intended to 
1)0 used to compare two anniversary Londsat classifications which have 
similar class structures. The resulting product of this comparison is a 
lJ\RSyS results tape containing "change" classes. 

Change classes are designated by the a;ialyst and are in the form 
where s 

Pine (time 1) goes to Non-Pine (time 2), and 

Non-stocked (time 1) goes to Stocked (time 2), 

Optimally, Landsat data la of an anniversary nature, tliat Is the data of 
collection for both dates Is nearly coincident but chronologically a year 
or more apart in time. Present requirements of the COMPARERESULTS pro- 
gram are that the Landsat scenes be precision registered. Independent 
classifications are generated for time 1 and time 2. The analyst is care- 
ful to insure that class structure, that is the various spectral groups 
chat comprise the information classes is similar. Once the classifica- 
tions have been generated, COJU’ARERESULTS is run and an output similar to 
figure 3.3.3 is produced. Tabular information which indicates the amount 
of change in aeres percent of area by class can also be produced. Pro- 
gram abstracts for COMPARERESULTS appear in Appendix B. 

2.3 Preprocessing Transfer 

This task involved transfer of the "front-end" software that is 
necessary to prepare the Landsat data for classification. A significant 
expenditure of effort was required for this task because of the complexity 
of the software and its level of documentation. Initially, a software 
definition or planning activity was required to define the specific com- 
ponents to be transferred to NCC. 

Software to handle the Landsat data formats, including the new P 
tape format, had been defined, programmed and transferred to St. Regis. 

An evaluation of the Landsat 3 data was made to define the extent which 
other proces# 0 ?s, designed to accomplish more precise scene registration, 
should be transferred. The other part of the preprocessing softv/are that 
was transferred included geometric correction software. 

Other major activities included under this task involved assisting in 
the development of a FRIS map coordinate system and defining the form and 
operations of a remote reformatting capability. 

LARSYS preprocessing software dcvelopmenc task resulted from a number 
of FRIS system design meetings which began in July of 1978. As of July 
1979, the FRIS system design had progressed to' a point that the LARSYS pre- 
processing and analysis software to be transferred to the St. Regis has 
been determined. LARSYS preprocessing software consists of three major 
processors. The three processors convert digital Landsat data to LARSYS 
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format, parform flysteraatlc geowatric corroctiona of Londnat data and 
register two images of landsat data. The requirement to systematically 
regioter a Landsat scene to a map or another Landsat scene, the image 
registration capability, was subsequently modified. The original re- 
quirement Included Implementing the image registration on the host main 
framo in Dallas, Texas and controlling job execution from the mini com- 
puter at Jacksonville, Florida. The selection by St* Regis, of a sophis- 
ticated software package to reside on the mini at Jacksonville , Florida, 
eliminated the need for the LARS image registration software. The regis- 
tration capability on the mini la more efficient, and therefore, more 
effective than the research software that was tentatively planned for 
Implementation. A discussion of the planned Implementation activity for 
this software module is included for Information. The final task beyond 
the transfer of software was the documentation of the software. 

2.3.1 Reformatting 

The first preprocessing system of programs converts digital Landsat 
data to a format compatible to LARSFRIS. The functional specifications 
for this processor required the conversion of input EDIPS Landsat MSS 
data. Including ne "p" format data, received in a band Interleaved by 
line (BIL) format to LARSYS format. "P" format refers to EDIPS format 
computer compatible tape data requested as GGT-"PM or fully processed MSS 
data with geometric corrections applied and resampled to a map projection. 
Details of this format may be found in the "Manual on Characteristics of 
Landsat Computer-Compatible Tapes" published by the EROS Data Center in 
December 1978 . 

Preliminary work on the design specifications to Incorporate the 
"P" format Landsat data processor began in early March 1979. In particular, 
the LARS reformatting group determined that a comprehensive design phase 
would substantially shorten implementation during the programming, de- 
bugging, and documentation phases. Work oh the design lasted into early 
July. Every algorithm was defined, program modules specified, and nearly 
all substantive variable and buffer areas were identified before pro- 
gramming began. The main routine, along with all subroutines and calling 
sequences, were thus determined and documented. The program design in- 
cluded accomodation for function specifications which would support both 
nearly automatic operations in an operational environment as well as 
multiple options required in a scientific resea/i'&h environment. 

Several techniques were utilized to solve this problem. First, the 
basic approach was top-down structure programming. All routines have a 
top to bottom flow of control, and top of calling sequences modules were 
programmed first. As much testing as possible was done after completion 
of each module and assembly of it with previously completed modules 
higher in the calling sequence. The second technique was to place a 
unique or substantive process in a separate module. Modules were allocated 
based on the structured "English" Version of the processing algorithm 
(Appendix C). The question asked by the analyst as he scans this "struc- 
tured English" program would be what processes must occur for this 
"sentence" or "group of sentences" to successfully execute. The answer 
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(!o£lned the modules to be programmed. Third, the primary programming 
language was FORTRAN IV utilizing the IBM Level 0 or H compilers. Some 
IBM Assembly Language program Includes the structured "English" versions 
of the algorithms used. 

In addition, the Implementation of the entire EDIRS to LARSYS pro** 
gromming task was PERT charted. This aided in the management of time and 
resources for the project. Parallel programming efforts could then be 
spotted as well as known or potential bottlenecks. Finally, to facilitate 
the control of the program in tlie most humonly efficient default mode, 
only three cards are required to execute the EDIPS processor. 

2.3.2 Geometric Correction 

The geometric correction processor was the second major system of 
programs. The geometric correction processors original functional speci- 
fications called for maximum correction of geometric distortions of 
Landsat I data with minimum use of resources. The most important dis- 
tortions thus were corrected. In particular, the data is assumed to con- 
sist of square 80 meter pixels which are rotated to true north, deskewed 
for the earth's rotation and rescaled for output on a line printer with 
8 X 10 aspect. In the context of FRIS pre-EDIPS format Landsat data may 
be corrected for geometric distortions. 

In the current FRIS image preprocessing system, this program may be 
utilized to rotate Landsat 3 data to true north and rescale it if necessary. 
This is especially important considering the number of data sources al- 
ready in true north orientation. Examples are the St. Regis Administrative 
Unit maps. Data in the same orientation is far easier to use for the 
human than data skewed or rotated relative to a given true north reference 
data set as the forest AU mentioned previously. For example, checkpoints 
are more readily defined and located as part of the image registration 
process. Relatively minor updates to the control card reader to in- 
corporate the rotation-only parameter were required to bring this program 
to a transferable status. Inspection and update of program listings, 
program abstracts, and user documentation were also required. 

2.3.3 Image Registration 

The last major processor contemplated was the image registration 
system. The primary purpose of this system was to register two coincident 
digital Images such as two Landsat digital image data sets. The secondary 
purpose was to provide for the registration of any known two-dimensional 
grid to another known or defined two-dlmsnsional grid. An example is 
the registration of Landsat data to a U.S. Geological Survey standard 
quadrangle map. The former has a grid X-Y of pixel locations while the 
latter has a grid of Inches and meters both horizontally and vertically. 
Input images are assumed to be in LARSFRIS format. Functional specifica- 
tions for the image registration system are given in Appendix D, The 
information in the appendix and the diecusslon which follows is provided 
only as inf orraatlon since this software was not implemented. Operationally, 
image registration is accomplished by the data base system acquired by 
St. Regis. 


The image registration system is a composite of research software 
developed at LARS and consists of three functional sections: 1) the moin 

image registration section^ 2) the coincident image cross-correlation 
section, and 3) the multlfit least squares analysis.. Wlille such software 
exists, it was never intended to be operational. A revised processot was 
desirable to achieve a more modern supportable software system. The 
writers of the old system are no longer available and documentation for 
the program was sparse. The procedure followed in this image registration 
system programming task followed that of the EDIP3 processor mentioned 
previously. Once the need for the new processor was established, func- 
tional specifications were determined. The overall goal was to produce a 
maintainable system which is modularized, as well as documented for pro- 
gram contents, programming techniques and user documentation. Further- 
more, the latest obtainable registration techniques have been used for 
implementation. No attempt was made to duplicate the Goddard MDP (Master 
Data Processor). The function of the system, however, is similar. Two 
Fytandard registration procedures were utilized to allow more accurate, cost 
efficient registrations. These activities occured prior to acquisition 
of the St. Regis data base software. 

The two implementation procedures were cubic polynomial for the over- 
all registration blocking with linear Interpolation. The first refers to 
the cubic polynomial whose coefficients are derived from the MULTIFIT 
processor. This processor uses least squares analysis to derive the 
best affine, bl-quadratic or bi-cubic fits for the checkpoints taken from 
the respective digital images or known grids as appropriate. With the 
best equation fit determined, normally a bi-cublc one, the blocking con- 
cept is utilized to reduce computation time. 

The concept of blocking during digital image registration is a 
moderately complex one. First, the bi-cubic polynomial for image location 
is investigated for rates of change and saddle points by solving the 
first and second derivatives. Utilizing these values one may determine 
the minimum block size within which a bilinear function accurately approxi- 
mates the bi-cublc one. Block size may be though of as Y lines by Z 
columns. At least "Z" number of multiple times are eliminated from the 
calculation of each pixel location within the block. Only the corner 
pixel locations of each block need to be calculated in full bi-cubic 
polynomial mode. The linear interpolation within the block is relatively 
fast and predictable with far fewer calculations. Should the bi-quadratic 
polynomial be the best fit for the data, blocking may still be used. How- 
ever, the reduction in the location calculation time will not be as great. 
In the unlikely event that a linear fit will suffice, blocking is not used. 

Other features of the registration system Include an automated cross 
correlation processor and two forms of pixel gray level interpolation. 

First the automated cross-correlation processor is an aid for acquiring 
checkpoint locations which are selected from two coincident Landsat digital 
image data sets. This cross-correlation will be accomplished by the imple- 
mentation of a numberical Integration image correlator. Control of where 
checkpoints are sought may be by line and column intervals and starting 
and stopping locations. Alternate control may be by a set of arbitrary 
checkpoints for location after cross-correlation. An appropriate initial 
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transformation will accompany either control method. Should this concept 
not be practical because of data dependency problems, manual checkpointing 
methods will be used. 

The second feature consists of a gray level Interpolation method. A 
gray level must be determined for each pixel location in the output grid. 

The nearest neighbor Is the default. The advantage of nearest neighbor 
Interpolation Is that no new data values are created. Classification al- 
gorithms may use the same statistics before and after registration. Cubic 
Interpolation of pixel gray levels is the alternative. This cubic inter- 
polation algorithm assumes surrounding pixels Input to the respective 
"center" pixel's gray level. The "center" pixel refers to the calculated 
subpixel location outputed from the registration polynomial. The pixel 
location is theoretically subpixel and the level of each surrounding pixel 
to the "center" pixel Is determined by which of the sixteen subpixel loca- 
tions is calculated for the "center" pixel. To facilitate the Implementa- 
tion of this third order Lagrange Interpolation, "center" pixels locations 
are calculated to one quarter of a pixel. Coefficients are pre-supplied 
in a table for each of the sixteen possible "center" pixel locations. The 
level of calculation is thus restricted to simple addition and multipli- 
cation. Cubic Interpolation of gray levels smooths the visual look of 
images. This approach has the potential for portraying slightly more 
accurate subpixel locations for given features of the scene. The cubic 
interpolation algorithm is described in Appendix E. Compared to the 
nearest neighbor interpolation technique, the cubic convolution approach 
requires more computer-resources. 

2.3.4 Preprocessing Documentation 

Documentation is a key to the technology transfer of the LARS image 
processing/analysis system totally known as LARSYS, Good documentation 
although expensive, was necessary to inform the programmer and user. The 
programs will be more maintainable by less readily knowledgeable programming 
professionals. Over the long term this potentially means less total time 
and expense. To the creator of the documentation, the effort means a more 
thorough knowledge of just what he or she has transferred to a fellow 
programmer in another organization. 

Documentation was the last major effort of the LARSFRIS preprocessing 
software implementation. Documentation consists of three main efforts for 
each of the three processors previously described. The three types of 
documentation were: 1) program listing documentation, 2) program module 

abstracts, and 3) user documentation. The first form of documentation 
was guided by a standards document (Appendix F) produced by the reformatting 
group at LARS. These standards expand and clear up details of program 
listing documentation to be followed in the preprocessing software. In- 
puts, outputs, ax'i)d major variables and arrays are detailed at the top of 
each program llsLlng under this standard. In addition, processing pro- 
cedures are clearly explained through comments in the listing. In essence, 
a new programmer should be able to read the comments within the listing 
and know what algorithm the code is implementing. 




Prograntming abstracts are the second form of documentation. These 
follow the IjARSYS standard manual. This form of documentation normally 
will be used with the program listing for maximum communication to the 
programmer . 

Finally, user documentation was generated. The user document 
describes what a processor Is used for as well as how to use It. Sample 
control card sets are Included alorig with explanations of what each set 
does. User documentation was designed to address how the program is 
run. Detailed Information on agloritiim implementation and function are 
not Included in this documentation. 

2.4 Land sat 3 Ev.iluatlons 

Prior to the launch of Landeat 3 in March 1978, NASA announced their 
Intention to upgrade the ground handling capability of the CCT data. Two 
elements of the announced change that were thought to have a significant 
and positive Impact on data users were: 

1) Improved data order turnaround, and 

2) Geometrically corrected and ground registered CCT data. 

Although order turnaround of data by the EROS Data Center (EDC) is 
not a critical aspect to most forestry applications. It was important to 
the successful operation of FRIS. Order turnaround, that is the elapsed 
time between the date of data collection and the date the user receives 
the CCT, was important to St. Regis if current Landsat data was to make a 
real contribution to the company's ongoing forest updating system. 

In order for Landsat data to be useful in FRIS, the data must be 
collected between the months of October and February. Not only must the 
data be collected during this time, but it must also be available to the 
system if the annual updating cycle is to be maintained. Availability to 
the system means that St. Regis will have; ordered, received, processed, 
and classified the data, so that those results can be reviewed when land 
managers review their annual updates. 

The key to meeting this time requirement rests with receipt of the CCT 
data from EDC. Historically, order turnaround from EDC was never better 
than 21-day and often order receipts could take upwards to 60-days. The 
announcement of a lO-day order turnaround time from EDC would help to insure 
the success of an operational FRIS. The improved order efficiency would at 
least make data available to the system faster and therefore help eliminate 
a bottleneck that was non-FRIS dependent. 

The second element of the new CCT format, the geometrically corrected 
ground registered scene, could also be a benefit to FRIS. The new Landsat 3 
data was provided by EDC to the user in a geometrically corrected by non- 
rotated format. The availability of geometrically corrected data has the 
potential to save the user both time and computer resources since these 
steps may be eliminated from the preprocessing sequence. However, this data 
is not rotated and therefore not corrected for north orientation. Since 
one of the uses of the Landsat data in FRIS will be to provide updated maps, 
the rotation of the data is an important consideration. 
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Conceptually, the Image rotation problem could be handled as a post- 
classification process In the FRXS mini-computer. This approach would 
involve classifying the data as received from EDC and then converting the 
classified data from an image grid (an image raster) to a set of classified 
vectors. The classified vecotrs would then be rotated using the appropriate 
transformation and overlaid and registered to the St. Regis ownership 
boundaries. 

Using the approach all the preprocessing activities with the exception 
of Landsat data tape reformatting would be eliminated. Only the refor- 
matting, image processing and possibly the raster to vector conversion would 
be performed on the mainframe. The remaining activities could be accomplished 
on a raiai-coraputer with suitable geo-ref erenceing software. Savings would 
occur primarily in the reduction of time necessary to prepare the data. 

Two important assumptions are necessary to enable this approach to work; 

1) EDO will operationally be capablle of providing geometrically 
corrected data, and 

2) The Landsat rotation and overlay can be suitable performed on a 
mini-computer. 

During Phase lit one Landsat 3 fully corrected data set was ordered, 

This data, designated as P-format, was available over the Picayune test 
Site in Mississippi. Data turnaround by EDC was within the specified 
announced time of 14-days. This acquisition proved the EDC was able to meet 
announced delivery dates. However, the test was not repeated so we have no 
way of knowing if this capability is operational. 

After receipt of the P-tape from EDC, a quick evaluation was conducted 
to determine if this data would eliminate the front-end preprocessing 
currently required prior to image classification. Another important pre- 
processing transfer activity involves the future potential use of fully 
corrected, P-format, data available from EDC. The availability of P-tape 
data to FRIS will eliminate much of the front-end preprocessing currently 
required prior to image classification. The discussion that follows gives 
preliminary results on the use of fully corrected Landsat 3 data from the 
Picayune teat site in southern Mississippi, figure 2.3. 1.1. 

The fully geometrically corrected Landsat MSS frames acquired for the 
forest resource data base are placed in a specific projection and orienta- 
tion. This makes possible a one-to-one correspondence between earth 
coordinates and row column pixel locations in the data. Having such a 
relationship for each frame will enable resource polygons on maps to be 
automatically related to row column locations in the data. Visual searching 
in the imagery would then be unnecessary once corner latitude, longitude, or 
UTM coordinates were known. A program was developed to enable user conversion 
of coordinates and some of the details are included here. 

The fully corrected MSS data are placed in a Hotine Oblique Mercator 
(HOM) projection and in the future they will be placed in the Space Oblique 
Mercator (SOM) projection. These projections are discussed in Appendix D 
of the new Landsat User's Handbook. The scale distortions of these pro- 
jections is very small (1:10,000); thus a linear transformation can accurately 
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Landsat 3, geometrically corrected data from the Picayune, 
MlBslssippl teat site has been overlaid with photog-aphlcally 
reduced ownership maps to Indicate the visual correlation of 
this new data type. 


Figure 2.A.1 
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be U8'v.d to relate points in the frame. The earth is divided into zones of 
latitude and within each zone the corrected frames have a constant azimuth. 
The zone covering the areas of interest here is zone 2 with latitude range 
23° N to 48° N and the ;?ne azimuth is 14.3394993°. The pixel scale of 
the fully corrected data is 57 meters in both directions. 

The software employed utilized a latitude-longitude to Universal 
Transverse Mercator conversion program to transform user input latitude- 
longitude coordinates first to UTM. Then a linear conversion was made 
to line column using the expressions: 

LINE - CLINE + DLINE 

COL - CCOL + DCOL 

DLINE (-DELEAS . SIN (ALPHA) - DELNOR . COS (ALPHA))/ 57 

DCOL - (DELEAS . COS (ALPHA) - DELNOR , SIN (ALPHA) )/ 57 

DELEAS - EAST - CEAST 

DELNOR - NOR - CNOR 

where: CLINE, CCOL are the center line and column of the frame. 

CEAST, CNOR ' is the UTM easting and northing of the center point. 

EAST, NOR are the UTM easting and northing of the poltit to be 
transformed to LINE, COLUMN. 

The conversion program (LOCPNT) was developed for interactive terminal 
use and required typing in the frame center latitude and longitude; then 
the user enters any number of latitude-longitude points in the frame he 
wants to convert. Problems were encountered in testing the program on 
the Picayune frame. Four test points were taken from the Nicholson and 
Dead Tiger Creek quadrangles in the Picayune frame and the latitude- 
longitude coordinates were input and the output line and column were ob- 
served. The input parameters are a part of the problem. A latitude- and 
longitude are given as the frame* format center; however, it was uncertain 
what exact line-and-column number corresponded to this. The bias observed 
at one of the test points was removed and the resulting center line column 
was taken as the format center. Thus, there is no error at this point. 

At the other three points, errors were observed. The results are listed 
in Table 2.4.1. 

The data presented in Table 2.4.1. suggests that the corrections 
supplied with the Landsat 3 data are not sufficiently accurate for precise 
registration to the ground. Although, this may be true of this particular 
scene, this data represents only a small sample. No conclusive statement 
can be made about the quality of the Landsat 3 correction system. 
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Tabic 2.4.1 Coordinate Conversation Tests for Picayune Frame. 

Format Centers 30.18°N., 89.52°W. Center Line, 



Col; 

1518 

,1796. 





Lat. 

Test 
Long . 

Point 

Line 

Col. 

Estimated 

Tiine 

Point 

Col. 

Error 

Line 

Col. 

30.375 

89.625 

1189 

1518 

1189 

1518 

0 

0 

30.5 

89,75 

987 

1265 

999 

1285 

12 

-7 

30,375 

89.5 

1150 

1725 

1141 

1724 

-9 

-1 

30.5 

89.625 

948 

1473 

952 

1463 

4 

-10 


However, the very exlstance of the geometrically corrected Landsat 
data sets are a benefit to the FRIS system. If this data can provide no 
more than a rudimentary correction that software within the data base 
can provide the final registration to the ground. The resultant regis- 
tration should meet the precision requirements of St. Regis and incur a 
time savings over a system that would have to start with uncorrected raw 
data. 

2.5 Technology Transfer Task 

Probably the most Important component of the entire System Transfer 
Phase involved transferring the computer-aided analysis capability to 
St. Regis staff. The basic elements of the system that were transferred 
included; hardware, software, and analyst capabilities. Hardware was 
assumed to be available or easily acquired. Software was modified or 
developed, and analysts were trained. Since the system is composed of 
the sum of its parts, all parts must be complete or a viable system could 
not be achieved. Hardware and softw< re acquisition and modification were 
relatively straight forward and easily attained. Preparation of a core 
of knowledgable analysts within the company was a somewhat more compli- 
cated task. The major en\pha8is of this task was to Insure that a useable 
capability was transferred to St. Regis staff. 

The foundation for the Phase III Technology Transfer activities were 
the results from the Phase II Demonstration. The decision by St. Regis 
staff to Implement the LARSTS software defined the type of training that 
St. Regis staff would be given. 

This task focused on educating St. Regis personnel regarding specific 
classification procedures associated with the use of Landsat tISS data. The 
success of. the technology transfer activity was paramount to the develop- 
ment of an independent remote sensing capability by St. Regis. This was 
an important goal defined at the Outset of the Project. Various activities 
Included : 

0 Support of a remote terminal hook-up between St, Regis at 
Jacksonville, Florida and LARS 
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0 Support of a remote ROSCOE terminal between the St. Regis National 
Computer Center (NCC) at Dallas, Texas and LARS 

0 Development of User Documentation 

0 System Transfer consultation 

0 On-site machine processing workshops 

2.5.1 Remote Terminal - LARS/JAX 

The remote terminal \ias the central theme around which all St. Regis 
in-house training was developed. Basic background about remote sensing 
was transferred to St. Regis personnel through various mechanisms. How- 
ever, these devices were not designed to provide hands-on analysis experi- 
ence. These activities v;ere reserved for Phase III. 

The remote terminal between LARS and Jacksonville, Florida went on- 
line at the beginning of Phase III. The terminal provided a focal point 
for training workshops to be held in Jacksonville, rather than at LARS. 

The in-house workshops did more than educate. They also converged the 
stability of the technology and committment to the concept by management. 
Thereby they formed the first phase of the orderly transition of the tech- 
nology from academia to industry. Working together during the beginning 
of Phase III, LARS and St. Regis personnel developed a training calendar. 

A preliminary training session was conducted during a week in June, 1979. 

A more detailed training session, which included "hands-on” training with 
the remote terminal was offered for one week in July, 1979. 

As part of the July training a user handbook was developed, see 
Appendix G. The handbook was designed as a step-by-step guide to LARSYS. 

It was set up to support the intermittent terminal user to easily access 
and conduct a classification session. 

2.5.2 Remote Terminal - LARS/NCC 

# 

Another terminal interface was employed during Phase III to help 
facilitate the orderly transfer of software from LARS to NCC. This involved 
a ROSCOE terminal link to the St. Regis National Computer Center. ROSCOE 
is a software package designed for interactive editing of batch jobs. 

This terminal link was intended to allow LARS staff to interact with 

St. Regis personnel during installation of LARSYS at the St. Regis National 

Computer Center. 

This capability was never extensively exercised because St. Regis 
staff were easily able to implement LARSYS. Conceptually the NCC terminal 
link would have saved both time and money if needed. 

2.5.3 Other Technology Transfer Activities 

A broad Variety of technology transfer activities, in addition to 
training St. Regis personnel and implementing software, were pursued during 
Phase III. These other related activities are discussed in some detail 
below. 
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A key element of the FRIS project plan addreased the dissemination 
of project related Information to the public. The project staff was able 
to take advantage of various forums to disseminate information about FRIS. 
These opportunities are discussed in chronological order of occurrence. 

0 November 1979 - Third Conference of the Economics of Remote Sensing 
Information Management Systems,, Incline Village, Nevada. 

The conference coordinators made an entire afternoon session avail- 
able for discussion of the Concept. This meeting was significant 
because it was the first public hearing of the economic analysis of 
the project, 

0 October 1980 - "Remote Sensing for Resource Managers Conference" 
Kansas City, Missouri. 

A comprehensive set of posters which defined the entire FRIS pro- 
gram was presented to a wide variety of professional resource 
managers . 

0 May 1981 - "Conference on Space Technology and Industrial Forest 
Management" Jacksonville, Florida. 

This conference was hosted by St. Regis, Purdue and NASA specifically 
to inform forest industry about FRIS. 

In addition to presentations made at professional conferences, papers 
were prepared for inclusion in the proceedings of the Incline Village and 
Kansas City meeting. No formal proceeding will accompany the Jacksonville 
meeting, since these results are reported in this and the St. Regis final 
project reports. 

Other published results of the project appeared in the "Congressional 
Record" (see Exhibit I) and as a project brochure. The FRIS project 
brochure was prepared to summarize the project goal, needs and describe 
its implementation and significance. The brochure was destrlbuted at the 
"Conference on Space Technology and Industrial Forest Management" and is 
available for general distribution to interested parties. 

The last and possibly most significant form of published project 
related materials consists of software documentation which was prepared 
for COSMIC. Thu software documentation, discussed in the previous section, 
is identified as LARSFRIS. This documentation consists of seven volumes 
of user manuals, system manuals, and program abstracts, and includes the 
information necessary for the preparation and processing of multispectral 
data sets. The documentation along with program listings in card image 
format on computer tapes will be generally available through COSMIC. 
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3.0 APPLICATIONS TEST 


Two related activities occurred during the System Trnasfcr Phase 
that highlight the benefits of Landsat data to forest management. The 
first involved the application of COMPARERESULTS software to assist 
St. Regis personnel assess a new land acquisition. The second involved 
use of the Landsat reflectance data to estimate crown closure. 

3.1 Knabb Tract Analysis 

In Jyly 1979 the project staff were given an opportunity to under- 
take an operational test of the technology. St. Regis had acquired a 
tract of land in Baker Gounty» Florida (figure 3.1.1). The new acqul- 
sitlonj here after referred to as the Knabb Tract, encompasses approxi- 
mately 40,000 acres of land and is ecologically similar to the Fargo 
test site. St. Regis staff were of the opinion that the timber removals 
had been extensive in recent years. Furthermore, they felt that removals 
were especially extensive since 1977. 

The application test was designed to address the feasibility of 
using Landsat classified data to: 

1) Evaluate the areal extent of the standing timber resource, from 
1979 data, and 

2) determine the change in standing timber that was detected by 
Landsat that occurred between 1977 and 1979. 

Our goal was to meet these objectives and to provide classification 
results by 1 November 1979. Timing was an important criteria to this 
application test because if the data could not be; 

Acquired 

Preprocessed 

Classified, and 

Final products available 

by the deadline, than the timeliness of the technology would be seriously 
questioned. In November the window for aerial photographic data collec- 
tion opens, and this tract was planned to be flown. If we were not able 
to provide Landsat Information by the time the photography is collected 
and interpreted then the utility of Landsat will be seriously questioned. 

Since the Knabb Tract is geographically close to the Fargo Test 
Site, it is therefore included On the same Landsat scene. The latest 
Landsat data available to the project was December, 1977. However, inad- 
vertently during reformatting part of the raw data, the part which in- 
cluded the Knabb Tract, was destroyed. 



A saarch was requested from the EROS Data Renter to Identify a suit- 
abXc set In the early 1979 time froraeT Du^ to ^ ground system modifica- 
tion, EDO was only able to provide data collected after February 1, 1979. 

A February 12, 1979 data set was selected for the second date. Both the 
December 1977 and February 1979 data sets were ordered In early August. 

The MSS data ordered In early August was received by mid-August. 

This rapid turn around provided by EDO was a tight requirement if the 
deadlines were to be met. The rapid turn around was a pleasant surprise, 
since data acquisition from EDO had previously been upwards of six months. 

The data was in two formats. The December 1977 tape was the old 
Landsat format. The February 1979 data was in the new landsat 3 format. 
This did not pose any problems in preparing the image overlay. The 
February data was expanded to fit the December data and the combined 
sets registered to the ownership channel. The only problem encountered 
with the February data Is that it appears to be excessively nolsey. 

Figure 3.1.2 Is an example of the December data for Baker County, Florida. 
Figure 3.1.3 shows the same data set with the ownership boundary channel 
overlay. 

During the latter half of August 1979, personnel from St. Regis 
Southern Timberlands were at LARS to prepare the ownership boundary 
channel for the Knabb Tract. Ownership boundaries were digitized, edited, 
connected, and check points located in the data within a one week time 
frame. In short, everything necessary to create the final data set up 
to but not including the data set registrations was completed by the end 
of August. 

The Knabb classifications Involved testing the feasibility to extend 
Fargo training statistics. Supplemental training were added Where appro- 
priate. Preliminary classification were field checked before final pro- 
ducts were prepared. The classification activity began as soon as data 
had been reformatted and coarsely corrected and before the final data 
set was ready for classification. 

A detailed discussion of the steps involved in the Knabb Test follows. 
3.2 Knabb Tract Data Preprocessing 

The primary preprocessing task Involved the registration of two 
Landsat frames to a 1:24,000 scale base map with property boundary infor- 
mation merged with the Landsat imagery. Although one of the Landsat frames 
(21050-14515) was available in-house, a portion of the frame required for 
the preprocessing was destroyed during an earlier process, necessitating 
the reordering of the data. The second data set, Landsat frame 21482-15101 
was not expected to arrive until 28 September 1979. Both Landsat frames 
would have to be reformatted to the LARSYS Version 3.1 format and geo- 
metrically corrected (systematic removal of first order distortions) to a 
scale of 1:24,000 with a line printer aspect (1QX:8Y). 
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Figure 3.1.2 Electrostatic printer greyscale output from Band 6 of 

the 1977 Landsat data of a portion of Baker County which 
Includes the Knabb Tract. 
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Figure 3.1.3 Data In figure 3.1.2 except that the Knabb Tract ownership 
boundaries have been included. 
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Since one of the intents of the test was to determine the timeliness 
of Landsat in providing land cover information, it was iwportant to com- 
j plete the preprocessing activity as quickly as possible. Using PERT 

planning, a probable completion date for reformatting was estimated as 
i 12 October ,1079. This date was based upon a starting date of 1 August 1979 

I and receipt' of the February 1979 Landsat data on 28 September 1979. Actual 

completion of the preprocessing task was 11 October 1979* 

Map digitization was performed by St. Regis Southern Tlmberlands 
i Division personnel. Originally a 1 inch to 1 mile map was to be digitized 

;! in the hope of eliminating the editing problem of digitally reconnecting 

, the maps. However, the boundaries to be digitized were drawn on 1:24,000 

scale uses quadrangle maps. A determination was made that accuracy would 
be lost by transferring the boundaries to the 1 inch to 1 mile map and 
then rescaling the data back to 1:24,000. A decision was made to digitize 
the boundaries directly from the USGS 1:24,000 scale maps and join the 
maps together digitally. This final method worked very well with no un- 
anticipated problems. A portion of the digitized data is shown in 
5 Figure 3.2.1. 

At the same time the maps were being digitized and the digital 
* boundary information edited the 7 December 1977 data was reformatted to 

■ LARSYS format and geometrically corrected. After completing the digitizing, 

14 checkpoints were located between the 7 December 1977 data and the 
uses quadrangle maps using the LARSYS IMAGEDISPLAY program. 

The 14 control points were run through an affine (6 parameter non- 
conformal) least squares fit. The resulting transformation function ex- 
hibited a line error of 0.708 root mean square error (rms) and a column 
error of 1.032 (rms). The following first order distortions were corrected 
by the transformation of the systematically corrected 7 December 1977 
data to the 1:24,000 USGS map coordinates: 

Scale X 1.0152 

Scale Y 1.0000 

Rotation 0.326 degrees 
Skew 0.0299 degrees 

At this point, both the digitized map boundaries and the Landsat data 
were in the same reference coordinate system. 

J , The next preprocessing step was to actually create the ownership 

f information in grid form. This was accomplished by "rasterizing" the 

I vectored digital boundary data. Some editing of an Intermediate file is 

i* normally required when the boundaries to be rasterized are of regular 

I rectangular polygons. This was the case of the Knabb Tract although 

i minimal editing of the intermediate file was required. The final result 

|1 was a tape in LARSYS format containing the precision (map) registered 

I] data with an auxiliary data channel containing ownership information. All 

Ij data outside of the ownership was set to a null value (hex 00) . 

h 

ii 

II 
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The second Landsat data set (21482-15101, 12 February 1979) arrived 
on September 28, The tape received was created in the newer EDIPS format 
rather than in the expected X (or older) format. The tape was reformatted 
using the new EDIPS to LARSYS reformatting software. 

ii 

Since the second data set was already corrected by NASA to eliminate 
radiometric and geometric distortions, It was necessary to correct only 
for rotation, scale, and aspect. The EDips corrected tapes are registered 
; * to a Mercator projection (either Ho tine o;r Space Oblique) using ground 

control. The resulting scale of this data set is approximately 1:17,952 
with each pixel representing a ground resolution of 57 meters square. 

* Since the current geometric correction processor is designed to correct 

for pixel size and skew, corrections already applied to the data by the 
NASA process, a transformation to correct for rotation, image scale, and 
pixel aspect using the image registration system was developed. The 
method for performing this type of correction through the image regis- 
tration system is described in Appendix H. 

The final step was to register the corrected second Landsat scene to 
the December 1977 data. A total of 185 checkpoints were located between 
the two images using the numerical autocorrelator of the image registra- 
tion system. An average correlation coefficient of 0.69 was obtained 
through 270 correlation attempts between the second channel of each scene. 
The average error between the predicted and observed checkpoint location 
was 0.67 pixels. The checkpoint pairs were then run through a biquadratic 
least squares fit. All control points were accepted with rms errors of 
0.099 in the line direction and 0.283 in the column direction. The 
following first order distortions were corrected by registering the 
corrected EDIPS Landsat scene to the map reference grid: 

Scale X 0.9999183 

Scale Y 1.0006683 

Rotation -0.1515851 degrees 
Skew 0.075 degrees 

3.3 Knabb Classification 

The acquisition by St. Regis of the Knabb Tract provided an oppor- 
- tunity to extend the classification procedures into an unknown area - one 

for which no photography or forest cover type information was available 
to the analyst to aid in defining a classification trainJ.ng set. In order 
I " save time the December 7, 1977 data was classified with the December 30, 

1976 training set. Normally this difference in data sets would have 
I caused serious, if not insurmountable, data calibration problems. In this 

case, however, the dates of data collection were both in December and were 
very near to the data of minimum sun angle. This, plus the fact that the 
weather condition were ideal over the training area in 1976 and the 
^ Knabb Tract in 1977 allowed the use of the 1976 training set with 1977 

data without calibration. The only significant classiflGation problem 
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was found to be the lack of a training class to represent the clear 
cut/site prepared areas which were present at the Knabb site but did not 
occur at Fargo. This deficiency was quickly corrected by adding two 
training classes generated from the Knabb 1977 data to represent these 
cover type conditions. A summary is shown In Table 3.3.1. 


Table 3.3.1 

Area statlstice 
classification 

for the Knabb Tract calculated 
of December 7, 1977 Landsat data 

from a 

Cover Type 

Acres 

Hectares 

Percent 

Pine 

22,723 

9,200 

52,2 

Pine/HardwoOd 

10,916 

4,420 

25.0 

Slash/Cypress 

8,275 

3,350 

19,0 

Nonstocked 

1,521 

616 

3.5 

Wet lands 

122 

49 

0.3 


43,557 

17,635 

100.0 


After this Initial classification was completed a new data set was 
received. This data set, collected on February 12, 1979, was overlain 
onto the 1977 data. Property boundary lines were digitized and added to 
this data set. A separate analysis was carried out using the previous 
classification augmented with information gathered during the field 
checking as training aids. The data quality was not nearly as good as 
that of the two previous sets. The 0.6-0, 7 micrometer band was unusable 
due to severe banding. The classification was done with the three re- 
maining bands. A summary of the classifications is shown in Table 3.3.2. 

In the two-year interval between the two data collections, several 
areas were cut and planted or were being prepared for planting. The two 
classifications were compared with the COMPARERESULTS processor to find 
and identify these areas and those results are shown in Table 3.3.3. The 
two original classifications are shown in figures 3.3.1 and 3.3.2 and the 
change map is shown in figure 3.3.3. 
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table 3.3.2 Area Btacistlca for the Knabb Trace calculated from a 
classification of February 12, 1979 Landaat data. 


Cover Type 

Acres 

Hectares 

Percent 

Fine 

25,487 

10,319 

58.5 

Pine/ Hardwood 

5,972 

2,418 

13.7 

Slash/CypresB 

10,959 

4,437 

25.2 

Monstocked 

719 

291 

1.7 

Wet lands 

420 

170 

0.9 


43,557 

17,635 

100.0 


Table 3.3.3 Area atntlatics for the Knabb Tract showing changes in 

ground cover which occurred between the two classifications. 


Change 

Acres 

Hectares 

Percent 

New Plantation 

7,686 

3,112 

17.7 

Harvested 

484 

196 

1.1 

No change 

30,634 

12,403 

70,3 

Unidentified 

change 

4,753 

1,924 

10.9 

43,557 

17,635 

100. 0 


Table 3.3.3 demonstrates the utility of multi-temporal Landsat classi- 
fications and a processor like COMPARERESULTS for updating basic forest 
inventory data. Because detailed ground data was not available when 
Table 3.3.3 was developed the chango classes identified were relatively 
broad. However, sufficient information was available to identify areas 
that were in new plantations, or forest lands that wore recently harvested. 
The unidentified clwinge class is most likely composed of areas being site 
prepared, burn areas, excessively wot areas, or any area whoso spectral 
composition was markedly different between the two dates. 

The ability to classify and compare anniversary Landsat data intro- 
duces new capabilities in monitoring the forest environment. The capa- 
bility now exists to take a "quick look” at the resource, compare these 
results with annual updates and assess the need for reinventory or de- 
tailed investigations of un-reconciled chhitges. Remote sensing and image 
processing will be able to provide basic resource Information that is as 
dynamic as the forest itself, thereby providing managers with a powerful, 
timely source of information , 
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Figure 3.3.1 Classification of December 7, 1977 Landsat data for the Knabb 
Tract. Area statistics for this classification appear in 
Table 3.3.1. 
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Figure 3.3.2 Classification of February 12, 1979 Landsat data for the 

Knabb Tract. Area Statistics for this classification appear 
in Table 3.3.2. 
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F igure 3.3.3 This is an example of a change nap which shows the areas which 
changes between the 1977 and 1979 classifications. Area 
statistics for the changes shown on this map appear in 
Table 3.3.3. 
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3.4 Ratio Evaluation 

During the course of the FRIS Project LARS Project personnel became 
aware of forest managements need to quantitatively relate Landsat and 
forest Inventory data, One approach that was especially noteworthy le- 
volved the application of regression analysis to Landsat MSS reflectance 
values. The predicted variable was the age of pine plantations, which Is 
an Indirect measure of crown closure. Crown closure Is a measure of stand 
stocking which 1s an Inventory measure. 

More precisely the ratio of the Infrared to visible band responses 
are assumed to be affected by stand occupancy, which Is reflected In 
crown closure. As stands mature. Individual tree crowns occupy a greater 
proportion of the site (figure 3,4.1). The Increasing crowii closure 
affects the ratio, which In preliminary tests corresponds well to a 
measure of age. 

3.4.1 Rnabb and Picayune Ratio Results 

The ratio of IR channels to visible channels from December 1977 
Landsat data fo.r the Knabb and Picayune tracts were used to predict the 
age of selected pine fields. The exact ratio used, the method of picking 
pine fields, the analysis used to predict the fields' ages and the re- 
sults of these predictions are outlined below. 

The exact data ratio generated was as follows; 

ratio » 40.0(03 + C4)/(C1 + 02 + 0,1) 
where 

01 « channel 1 

02 ■ channel 2 

03 « channel 3 

04 " channel 4 


The multiplier 40.0 and the constant 0,1 were needed to enhance the range 
of and information In the data, and to prevent a divisor of aero. 

The Knabb Tract was first categorized into pine and non-pine classes. 
From this classification fourteen fields of seemingly homogeneous pine 
were selected and tha average ratio for each field was determined . Due 
to the proximity of this tract to the Fargo test site and their similar 
physiography, a regression equation developed for Fargo was used to 
predict the ages of the selected Knabb fields. Four of the Knabb fields 
were dropped from further analysis. Two of these discarded fields were 
accidently picked outside the Knabb boundaries and the other tv^o dropped 
fields were Inaccessible for checking ground truth. Of the ten pine 
fields left, a ground Inspection of the area established that (1) all ten 
fields were pine, and (2) nine of the ten fields had ages within the ninety 
percent confidence Interval for each predicted age* Ages were derived by 
taking Increment cores and counting growth rings of randomly selected 
dominant trees. 


® 0 
0 0 ^ 


Figure 3.4 



.1 This ia a conceptual representation of the biological growth, 
response over time. The basic hypothesis of a ratio evalua-'t 
tion assumes that as a plantation matures the reflectance of the 
tree crowns will be the dominant factor affecting the calculated 
ratio. Therefore, this measure of crown closure can be related 
to stand age. 


* 


Table 3«4tl shows the preliminary results obtained by applying the 
Fargo prediction equation to the ratio calculated from Landsat data over 
the Knabb Tract. 

Similarly* ten pine fields were chosen from the Picayune Test Site 
and the predicted age of each field was determined from an equation 
developed specifically for the Picayune data. The age for each field 
was verified by ground investigation. Table 3.4.2 shows the preliminary 
results . 


Table 3.4.1 

Preliminary results 
Tract. 

for ten pine plantations in the Knabb 

Fields if 

Age Measured 
on site 

Age Predicted 
from Landsat Ratio 

90% Cl on 
predicted age 

1 

30 

19 

(9.4* 37) 

2 

40 

26 

(13, 51) 

3 

16 

24 

(12, 46.7) 

4 

24 

16 

(8, 31) 

6 

32 

12 

(6, 25) 

7 

16 

20 

(10, 40) 

8 

14 

27 

(14, 54) 

10 

5 

4 

(2, 9) 

13 

29 

19 

(9.5, 38) 

14 

18 

17 

(8, 33) 


Prediction Equation: 


IoSj^qCAGE + 1) - -9.333088 + 5.567559 log^pCratlo) 
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Tabic 3. A. 2 Pcellrolnary trials of an age prediction equation using 
Landsat ratio values for Picayune, Mississippi , 


Field 

Ground 

Verified Age 

Age Predicted 
from Landsat Ratio 

1 

15 

17 

2 

18 

9 

3 

14 

10 

*4 

26 

6 

5 

2 

3 

6 

14 

10 

7 

13 

18 

8 

0 

1 

*9 

26 

9 

10 

14 

16 


Prediction Equation: 


log^Q(AGE + 1) - -A.91363A + 3.218647 logj^g (ratio) 

*Both these fields had actual ages beyond the range of the regression 
equation. Of the ten Picayune fields checked, two (fields 4 and 9) fell 
outside the 90% confidence interval for the predicted age. 

Another application of the generated ratio channel was a classifi- 
cation of the Knabb area done solely with the ratio channel (LEVELGIiASSIFY) , 
Analysis done on the Fargo test site revealed the fact that the average 
ratio of hardwood fields in winter data fell below the average ratio of 
pine fields. Hence using the ratio intervals developed on the Fargo test 
site, the Knabb Tract was classified into hardwood, young pine (less than 
15 years old) , and old pine (15 years old or over) . 

Since the levels for the level classifier were determined using 
averages over fields, these levels did not apply directly to classifying 
pixels. Also the levels were determined on another site causing even 
more Inherent Ct-ror in this classification. The ten pine fields used 
in Table 3.4.1 and four hardwood fields were used to test the accuracy 
of this classification. The results are presented in Table 3.4.3. 
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Table 3. 4 ,.3 Classification performance for a LEVELCLASSIPY approach 
using Landsat ratio input for the Knabb Tract. 

Classes 

Classification accuracy 

young pine 

45.8 

old pine 

57.4 

hardwood 

60.0 

overall accuracy "57.4 



Honce the ratio of IR to visible Landset channels has shown usefulness 
In predicting the ages of pine fields even over areas with no ground truth. 


Preliminary results using the generated ratio as o classification 
channel, however, has shown questionable usefulness. This does not pre« 
elude further investigation of levels classification technology. The 
levels classifier is significantly faster than a maximum likelihood per- 
point approach and could therefore be beneficial for ''first look" evalua 
tlons of large areas. Additional Investigation into the application of 
this approach needs to be pursued « 
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4.0 BENEFIT/COST ANALYSIS 


The unique composition of the FRIS Application Pilot Study intro- 
duces some complications when conducting a bonefit/cost study. Normally, 
publicly funded projects are evaluated by utillulng a "social'’ benofit/cost 
approach where maximizing net social benefit is the dominate objective. 
Therefore, all benefits and costs are adjusted for market failures or 
externalities. In addition, the problem of defining what constitutes a 
benefit or cost a..d to whom various benefits and cost are accruing is 
more complex in the social case then in the private analysis. However, 
since STR is a privately owned corpora ;lon, it uses a private benefit/cost 
analysis approach when making capital investment decision. These 
decisions are different from the social benefits and costs in that market 
externalities are not considered (Dasgupta, et al., 1972). 

4.1 Social Benefit/Coat - A Conceptual Approach 

NASA funded the FRIS project with the expectation that the demon- 
stration of a viable forest information system using LANDSAT imagery 
will Increase the use of LANDSAT in the forest products industry. With 
the addition of this better information, forest managers should be able 
to more efficiently manage their resources and Increase productivity. 

This Increased productivity could result in decreased costs of production 
and thus lower consumer prices. 

Figure 4.1 is a simple supply/demand model for a hypothetical forest 
product. The line ABCD is the demand curve for the product. SI and S2 
are supply curves (i.e., cost curves for the production of the product). 

If before FRIS SI is the supply curve, the price of the product is PI and 
quantity F is demanded. The net consumer surplus in AB PI (Mlshan, 1976, 
pp. 416-429) . Assuming that the Information developed by the FRIS pro- 
ject reduces the costs and thij supply curve is shifted to S2, the con- 
sumer surplus is AC P2. The net* increase in consumer surplus is PI BC P2 
(AC Ps - AC PI), The basic question is whether the Increased consumer 
surplus is equal to or greater than the project costs. 

Unfortunately, there is no way to estimate the forest products 
industry's response to the FRIS technology or if in fact a lowering of 
the supply curve will occur. However, some analysis can be accomplished 
which will provide a feed for the level of magnitude of a supply curve 
shift which would Justify the Initial coats. To develop this estimate, 
the following assumptions are made: 

1) The price elasticity of demand for paper is - 0.2 (Haynes, 

Holley, and King, 1978). 

2) It will take 10 years for enough firms to adopt the FRIS tech- 
nology to result in a one time reduction In the aggregate 
supply curve. 
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Figure 4 


ORIGINAL PAGE IS 
OF POOR QUALITY 



.1 The consumer surplus from a decline In the supply curve from 
SI to S2 Is Pi B C P2. 



3) The present trend of 2.4 percent per/annum increase li> paper 
consumption will continue through 1990. 

4) The present trend of 6.8 percent per/annum Increase In price 
will continue through 1990. 

5) The social rate of discount Is 10 percent per/annum. 

6) All costs of Implementing the future FRIS systems are borne by 
the firms from private proflts> l.e., there are no additional 
public costs. 

The net social benefit of the FRIS project can then be calculated by: 
NSB - DCS - DC 

where NSB ■ net social benefit 

DCS “ discounted consumer surplus In year 1990 
DC * capitalized or discounted costs 

Annual project costs are; 1977 - $21,983; 1978 - $214,404; 

1979 - $235,008; 1980 - $183,842. The consumer surplus resulting from a 
shift In the supply curve can be estimated by multiplying the amount of 
the price decrease times the original quantity (Pi j?2 EB, Figure 1) plus 
one half of the price change times the quantity cimnge (BCE, Figure 1) . 

Since the price elasticity of denmnd is known (- 0.20), it is 
possible to estimate the consumer surplus occurring if the supply curve 
is shifted. Two shifts are considered here. One shift results in a 
0.1% price decrease, the other a 0.01% price decrease. The corresponding 
quantity increases are 0.02% and 0.002% respectively. The calculation of 
the consumer surplus assumes an initial price of $740/ton and consumption 
of 47,282,919 tons in 1990. Thape levels were calculated by compounding 
the current price and consumption by the annual rates of increase 
Stated in the assumptions. 

Table 4.1 gives the results of this analysis. It can be seen that 
it will take very little effect on the costs of production to recover 
the cost of the FRIS profit given the assumptions stated above. These 
calculations also do not include the potential affects on paperboard, 
speciality papers, of any solid wood products. Clearly if the FRIS pro- 
ject does lead to increased supply and lower production costs, the public 
funds were well spent. 



Table 4.1. Net social benefit (NSB) calculation. 


Year 

Item 

Actual 
Cost ($) 

Time 

Adjust. 

Present 
Value ($) 

1977 

Project Cost 

-21,983. 

1.3309 

-29,259.37 

1978 

Project Cost 

-214,404. 

1.2099 

-259,428.84 

1979 

Project Cost 

-235,008. 

1.1000 

-258,596.80 

1980 

Project Cost 

-183,842. 

1.000 

-183,842.00 

1990 a 

Consumer Surplus 

35,036,836. 

0.3855 

13,506,700.00 

b 

Consumer Surplus 

3,503,368. 

0.3855 

1,350,548.00 

NSB a 

From 0.1% price reduction 


12,775,573.00 

b 

Prom 0.01% price 

reduction 

* 

619,421.00 


4.2 Private Beneflt/Cost Analysis 

The aggregate supply curve will fall only if a large number of firms 
adopt a FRIS type system leading to widespread improvement in forest 
management and productivity. Forest products firms will adopt the tech- 
nology only on the basis of a private, not social, benef it/cost analysis. 

A private benefit/cost analysis is technically identical to sccial 
benefit/cost analysis, in that, both discount benefits and costs to ob- 
tain net present values or internal rates of return. The major difference 
between the social and private analysis is in the definition of a cost or 
benefit. For private firms, there are no externalities by which the 
benefits or costs are adjusted from the observed market price. For 
example, in social analysis, taxes are not considered a cost, but simply 
a redistribution of wealth. To the private firm, taxes are definitely 
considered a cost of production, and thus reduce profits. 

If the objective of the project is the increased use of LANDSAT by 
the private sector, the critical analysis is that of the private firm. 

The technology will be accepted or rejected on the basis of the private 
benef it/cost analysis. Therefore, STR acceptance of the project and 
Implementation of an operational system is the best measure of the success 
of the project. By this measure the system is acceptable on a private 
benefit/cost basis. Reports issued by STR on this project will detail 
that part of the private benefit /cost analysis. 
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APPENDIX A 


Lists of Preproisessing and LARSYS Software that was transferred to NCC 
Preprocessing Subroutines 


ACCNT 

DISMAT 

FDRITE 

LNDERR 

LNDSUM 

BINSCH 

EOT 

JTOR 

LNDF17 

LNDSUP 

CASCII 

ERRPTR 

LARS17 

LNDHED 

LNDTRA 

CHAR 

FILEOP 

LNDANC 

LNDIMA 

LNDVAL 

COHDMP 

PILSRH 

LNDANN 

LNDINT 

LNDWRT 

CPTIME 

GCTROL 

LNDARC 

LNDLID 

LNDWP 

CTLCBC 

GEtlANG 

LNDBIL 

LNDMIL 

PAGLOC 

CTLSPN 

GEMCHK 

LNDCOL 

LNDPAG 

STDHDR 

CTOlAl 

GEMGOM 

LNDCOR 

LNDPRM 

TAPMC 

DISK 

GEMCOR 

LNDCTL 

LNDRDR 

USAGE 

DISKOP 

GETACT 

LITODIR 

LNDSTR 

XMOUNT 


Major LARSYS 

and LARSYSDV 

Routines 



LARSYS 


LARSYSDV 



PICTUREPRINT 

BIPLOT 

STATISTICS 

COMPARERESULTS 

IDPRINT 

CLUSTER 

LISTRESULTS 

SMOOTHRESULTS 

PUNCHSTATISTICS 

SEPARABILITY 

LINEGRAPH 

CLASSIFYPOINTS 

COLUMNGRAPH 

PRINTRESULTS 

HISTOGRAM 

CHANNELTRANSFORM 

GRAPHISTOGRAM 

COPYRESULTS 

COPYRESULTS 

MERGESTATISTICS 

EXCOMAND 

RATIOMEANS 


SECHO 
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Al’PENDIX B 


Example of control card reference files and program abstract for the 
LARSFRIS program COMPARERESULTS . 


Note; This program makes comparisons between user specified classes 
that occur on two classifications. 
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LARS Program Abstract 380 

MODULE IDENTIFICATION 

Module Name; COMSUP Function Name; COMPARERESULTS 

Purpose; Supervisor for the function. 

Svstem/Lanquaqe; CMS/FORTRAN 

Author; John Cain D ate; 6/1/79 

Latest Revisor; ^ Date; 


MODULE ABSTRACT 

Supervisor for the COMPARERESULTS function. 


PURDUE UNIVERSITY 

Leiboratory for Applications of Remote Sensing 
1220 Potter Drive 
West Lafayette, Indiana 47906 

Copyright © 1980 

Purdue Research Foundation 
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COMSUP-2 


1. Modulo Usage 
CALL COM3 UP 

There are no arguments to COMSUP. It is called from LARSMN when 
the COMPARE RESULTS function is requested. Control returns to ■ 
LARSMN upon completion of the function. 


2. Internal Description 

COMSUP receives control from LARSMN to perform the COMPARERESULTS 
processing. COMSUP calls COMRDR to read and interpret the control 
cards. Upon return from COMRDR, COMSUP calls CHANGE to finish the 
processing. Subroutines called by COMSUP; COMRDR 

CHANGE 


3. Input Description 
Not Applicable 


4 . Output Description 

Message numbers are listed below, see User's Manual for text of 
message. 


MESSAGES 

INFORMATIONAL 

I 26 
I 264 

5 . Supplemental Information 
Not Applicable. 


6 . Flowchart 


Not Applicable. 
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LARS Program Abstract 

MODULE IDENTIFICATION 

Module Name ; COMCOM Function Name; COMPARERESULTS 

Purpose s Block data 

System/Language : CMS/FORTRAN 

Author: John Cain Date: 6/1/79 

Latest Revisor: . Date: 


MODULE ABSTRACT 

This is the BLOCK DATA subroutine for the COMPARERESULTS common 
block COMCOM. 


PURDUE UNIVERSITY 

Laboratory for Applications of Remote Sensing 
1220 Potter Drive 
West Lafayette, Indiana 47906 


Copyright © 1980 

Purdue Research Foundation 
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LARS Program Abstract 382 

MODULE IDENTIFICATION 

Module Name; COMRDR Function Namo ; COMPARERESULT S 

Purpose: Reads and interprets function control cards, 

System/Language « CMS/FORTRAN 

Author: John Cain Date : 6/1/79 

Latest Revisor: Date: 


MODULE ABSTRACT 


COMRDR interprets all function control cards for COMPARERESULTS. 
Checks are made for complete and valid specifications and the 
proper input~output devices are attached. 


PURDUE UNIVERSITY 

Laboratory for Applications of Remote Sensing 
1220 Potter Drive 
West Lafayette, Indiana 47906 

Copyright @ 1980 

Purdue Research Foundation 
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» 


« 



Output Arguments ; 


Z’^LOGICAL*! each element initialized to .FALSE. 

Z (i/1, j) “.TRUE. - if class i from the first classifi- 
cation is part of user-defined class 

3 • 

Z {m/2,n)“.TRUE. - if class m from the 2nd classifica- 
tion is part of user“defined class n. 

NAME-I*4 - contains the names of the user-defined classes. 


Listed below are the actions taken when the following control 
cards are read. 

PIRSTRESULTS TAPE - the variable TAPEl (TAPE2) is set 

(SECONDRESULTS)[ to the given tape number. 

PILE - the variable PILEl (FILE2) is set 

to the given file number. 

DISK - DISKFG is checked to be sure that 
the DISK option is not already in effect, 
the tape and file numbers are checked to 
be sure that both the DISK option and 
TAPE option are not being used simultan- 
eously. If they are, then an error mes- 
sage will be printed and the DISK will be 
used, 

RESLTl (RESLT2) is set equal to CLASSR. 

NEWRESULTS TAPE - the variable TAPES is set equal to 

the given tape number. 

FILE - the variable FILES is set equal to 
the given file number. 

INIT - the variable INITFG is set equal 
to 1. 

DISK - the same checks are made as above 
in addition to a check to see whether the 
INIT and DISK option were used simultan- 
eously. DISKFG is set equal to one and 
RESLTS is set equal to CLASSR. 

BLOCK RUN - the variable RUNNUM is set equal to 

the given run number. 

LINE - STALIN is set equal to the first 
entry (the starting line of the area to 
be investigated) . LASLIN (last line) is 
set equal to the second entry and finally 
LININT (line interval) is set equal to the 
last entry. 

COL - same as above where the variables 
are: STACOL - first entry, LASCOL - second 

entry and COLINT - final entry. 
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COMRDR-3 


data a chock is mode for the presence and va- 

lidity of all information. 

CLASS name The name given is stored in the array 

NAME. 

FIRST Nl, N2,.,, Using the given class numbers the appro- 
SBCOND Ml, M2,... priato locations in the Z(64,2^64) array 

are set .TRUE. 

(i.e. if these are the FIRST and SECOND 
cards for the jth user-defined CLASS, then 
the following assignments are made for 
array Zs 

Z(Nl,l,j) 

Z(N2,1, j) 

and 

Z(Ml,2,j) 

Z(M2,2,j) 


2 . Internal Description 

GOMRDR uses the standard card reader logic in using CTLWRD, CTLPRM 
and IVAL to read and interpret control cards. 

COMRDR begins by initializing all flags and arrays that are used 
to convey control card information. It then goes into a loop of 
reading and interpreting the input specifications and the BLOCK 
card. When the DATA card is read GOMRDR checks for the presence 
of all information and its validity. Another loop is entered and 
the CLASS cards and their corresponding FIRST and SECOND cards 
are read. The class numbers from the FIRST and SECOND cards are 
used to set appropriate values in the Z array to a logical .TRUE. 

Z (i,l, j) = .TRUE. if the Ith class from the FIRST results file is 
part of user-defined class j . 

Z (k,2,m)-.TRUE. if class k from the SECOND results file is part 
of user-defined class m. 

This loop is exited when an END card is read. Once this card is 
read, COMRDR calls CHTAPE to mount the specified tapes. If a disk 
was specified as an input device, GOMRDR first checks to be cer- 
tain both a tape and disk were not specified for a single input. 

It then reads from the results file to be sure it exists on the 
disk. If a disk was specified as an output device, checks are made 
to be sure there is sufficient space for the output results. TSPACE 
makes a search for a larger disk if necessary. COMRDR finally re- 
turns control back to COMSUP. Subroutines called by GOMRDR: 

CTLWRD CTLPRM TSPACE 

BCDFIL CHTAPE RTMAIN 

IVAL ERPRNT 


« .TRUE. 
» .TRUE. 


» .TRUE. 
» .TRUE. 
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COMRDU-4 


3. Input Dcii^^rlptlon 

Function control cards for COMPARERESULTS ore read via CTLWRD. 

4 . Output Description 

Message numbers are listed below^ see User's Manual (vol. 3) for 
text and explanation of message. 

MESSAGES 

INFORMATIONAL ERROR 

10261 E620'*E633 

X0262 

5 . Supplemental Information 
Not applicable. 

6 . Flowchart 


Not applicable 
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LARS Program Abstract 383 

MODULE j^DENTIFICATIOW 

Module Name:, COMPAR Function Name: COMPARERESULTS 

Purpose : Compare 2 lines of classification results 

System/Language : CMS/FORTRAN ... .. 

Author: Susan Schwingendorf Date: 3/28/79 

Latest Revisor * 


MODULE ABSTRACT 


COMPAR compares two lines of classification results (presumably from 
two different classifications which are registered to each other) 
against user defined change classes in a logical array ^ and writes 
the output class number in the output vector* 


PURDUE UNIVERSITY 

Laboratory for Applications of Remote Sensing 
1220 Potter Drive 
West Lafayette, Indiana 47906 

Copyright © 1980 
Purdue Research Foundation 


59 


COMPAR-2 


1. Module Usage 

CALL COMPAR (NCOLS ,NCLASS , Z , BUFPl ,DUPF2 ,DUPP3) 


Input Arguments; 


NCOLS 

NCLASS 

Z 


BUFFI 


BUPP2 


INTEGER*4 , the number of columns of classified 
data. 


INTEGER*4 f the number of classes defined by 
the user in array Z. 

LOGICAL*! (64, 2, 64) array containing user 
defined change classes. (Initialized to 
.FALSE.) 


Z(I,1,K) = .TRUE. 
Z(J,2,K) = .TRUE. 


means a point in class 


I from classification 1 (BUFFI) and in class 
J on classification 2 (BUFP2) should be as- 
singed to class K in BUPF3 . 

LOGICAL*! (2*NC0LS + 4) vector containing 
classified data from first classification. 

First full word is line number. Then the 
second byte of each halfword contains the 
next class number. 

LOGICAL*! (2*NCOLS + 4) vector containing 
classified data from the second classification. 
First full word (4 bytes) is the line number. 
Then the second byte of each halfword con- 
tains the next class number. 


Output Arguments ; 

BUPP3 - LOGICAL*! (2*NCOLS +4) vector of change 

classes for this line. The first full word 
contains the line number. Then the second 
byte of each halfword contains the assigned 
change class number. 


2 . Internal Description 


The line number is written in the first word of BUPP3 . The next 
class number is then extracted from BUFFI and BUFF2 and assigned . 
to integer variables CLASSl and CLA.SS2. A loop through the logi- 
cal array Z determines which output class to assign this point to. 
If Z (CLASSl, l,j) and Z (CLASS2,2,J) are true, then the point is 
assigned to class J. If it belongs to none of the defined out- 
put classes, then it is assigned a class number NCLASS+1. The out 
put class numbers are written in BUFF3. 
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3. Input Doscription 
Not Applicable. 

4 . Output Doscription 
Not Applicable. 

5. Supplemental Information 
Not Applicable. 

6 . Flowchart 


Not Applicable. 
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LARS Program Abstract 384 

MODULE IDENTIFICATION 

Modulo Marne ; CHANGE Function Ncuno; COMPARERESULTS 

Purpose: Compares two classification results file- and outputs the compared' 

results . 

Systera/Language ; CMS/Fortran 

Author; John Cain Date; 6/1/79 

Latest Revisor; ^Date: 


MODULE ABSTRACT 


CHANGE is the main subroutine for COMPARERESULTS . It reads from two 
input tapes (or one disk and one tape ) , calls COMPAR, then outputs 
the data in standard LARSYS classification results file format to 
tape or disk. 





PURDUE UNIVERSITY 

Laboratory for Applications of Remote Sensing 
1220 Potter Drive 
West Lafayette, Indiana 47906 

Copyright © igeo 
Purdue Research Foundation 
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CIlANGE-2 


oummi iPAQE IS 

1. Modu le Usage OF POOR QUALITY 

CHANGE 

CALL CHANGE (Z, NAME) 

Input Arguments ; 

Z-Ligical*l - Z (i ,1 , j ) = .TRUE . if class i from the first 
classification is part of user-defined 
class j . 

Z (m,2 ,n)=.TRUE, if class m from the 2nd 
classification is pArt of user-defined 
class n. 

NAME - 1*4. - Contains the names of the user-defined 
• classes. 

Output Arguments ; 

Not Applicable. 


2. Internal Description 


CHANGE first reads the file numbers from the input tapes, and the 
tape numbers passed through the common block, and creates a code 
that takes the place of the CLASSIFICATION STUDY number. The code 
format is the first tpae and file numbers followed by the second 
tape and file numbers. CHANGE then reads the area identification 
record (record type 5) from both input sources and checks to see 
whether they are valid for the given BLOCK CARD; if not, appropri- 
ate error messages are printed and the function is terminated. 
Record types 1-5 are written to the output tape (DISK) . The inputs 
are positioned to the correct line number and shifted to the cor- 
rect column number. CHANGE then calls COMPAR to determine which 
class each point belongs to and this information is used to create 
file type 6. Finally record types 7 and 8 are written and control 
is returned to COMSUP. If the output device is a tape, then a fi- 
nal record type 1 and END or PILE Mark are written before returning 
to the supervisor. Subroutines called by CHANGE: 

COMPAR 

RTMAIN 

TAPOP 


3 . Input Description 

Record types 1, 5, 6 of the LARSYS classification results files 
are read from the two input devices, RESLTl and RESLT2 . One of 
these may be a disk (DSRN CLASSR) . Tape drives 181 (CPYOUT) and 
182 (SCNDTP defined in GOMCOM) are used as inputs. 
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4 . Output Description 

The output device RESLT3 initially has a DSRN of MAPTAP. If a disk 
is used (only if one is not used for input), the LoRN’is changed 
to CLASSR. Tape drive 180 is used for output to facilitate the run 
of PRINTRESULTS on the output data immediately after the COMPARE- 
RESULTS run. The output is a classification results file in standard 
LARSYS format. 

Message numbers are listed below, see User's Manual for text and 
explanation of message. 


MESSAGES 


INFORMATIONAL 


ERROR 


10263 


E634-E638 


5. Supplemental Information 
Not Applicable. 


6 . Flowchart 


Not Applicable. 
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LARS Program Abstract 385 


MODULE IDENTIFICATION 
Module Name ; CHTAPE 


Function Name t comparerrsults 


Purpose; Mo unts and positions results tapes 

System/Language ; CMS/FORTRAN 

Author: 


Date ; 9/5/72 


Latest Revisor; Cain 


Date: 6/1/79 


MODULE ABSTRACT 


CHTAPE mounts and positions the results tape (or a tape to be used 
as output for copying results files.) 


PURDUE UNIVERSITY 

Laboratory for Applications of Remote Sensing 
1220 Potter Drive 
West Lafayette, Indiana 47906 

Copyright @ 1980 

Purdue Research Foundation 
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CUTAPE-2 


1. Module Osage 
CHTAPE 

CALL CHTAPE (RQTAPE,RQFILE, MODE, UNIT) 


Input Arguements 

RQTAPE - 1*4. Tape number of requested tape. A 
tape number of 0 is a request for 
a scratch tape. 

RQPILE - 1*4. Pile number of requested file. If 

RQPILE is = 0, then the tape will be 
initialized by writing a record type 
1 on the results tape with filetype= 

0 . 


mode “ 1*4. Flag indicating usage of CHTAPE. 

MODE = -1 indicates CHTAPE has been 
called to mount and position a tape 
to be used for copying results files 
onto. MODE = 0 indicates that a 
results tape is being mounted for 
reading a results file. In this 
case, the tape is mounted ring out. 
Also, if MODE = 0, RQPILE = 0 is 
invalid and will cause an error when 
an attempt is made to write on the 
tape. MODE = 1 indicates a tape is 
being, mounted for writing a new re- 
sults file (or continuing a suspended 
classif icaiton) . Since the unit 
value is passed in the call, Mode(l) 

= Mode(-l) . 

UNIT - 1*4. DSRN of tape being mounted. 


Output Arguments 

RQTAPE - 1*4. When MODE = 0, set to -1 if requested 
tape file was full and user decided 
to use disk for results. Otherwise, 
remains unchanged. 

RQPILE 1*4. When MODE = 1, set to -1 if requested 
tape file was full and user decided 
to use disk for results. Otherwise, 
sends back current file position of 
tape. 

CHTAPE checks the validity of the tape by reading the record type 
1 from the tape and verifying the tape and file number as well as 
checking for the correct type of file. Any attempt to overwrite 
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an existing file causes CHTAPE to ask the user (via the typewriter) 
if he v/ishes to overv;rite the file, rcspccify a now results card, 
or terminate the function* Note, however, that if a request has 
been made to initialize a tape, no checking is performed on pre- 
vious contents. 


2* Internal Description 

See Output Description. Subroutine called by CHTAPE; 

TAPOP RINGIN IVAL 

MOUNT CTLWRD ERPRNT 

CPFUNC CTLPRM RTMAIN 


3. Input Description 

The record type 1 of the results tape is read for each file up 
to and including the file needed. That is, if file 4 is re- 
quested the record type 1 is read from files 1-4. 


4. Output Description 

The following information messages are issued under the cir- 
cumstances listed. The term filetype means the filetype code 
from record type 1 of results file (the program uses variable 
CHECK for this number) . 

10042 is typed when a tape has been mounted and before 
CHTAPE positions it. This message is not typed 
when the tape is being initialized or when the 
correct tape number was already mounted. 

10043 is typed when MODE = +1 and filetype of the requested 
file =0. 

10044 is typed when MODE = +1 and filetype of the requested 
file " 1 and the restart flag from GLOCOM (RESTRT) is 
not =1. 

10045 is typed when the tape is correctly positioned. This 
is not typed when initializing a tape. 

After 10043 and 10044, the user is asked whether he wishes to 
overwrite the file, respecify a new results card with a new 
tape and/or file or disk option, or terminate the function. 

10100 is typed to allow entry of the new results card. This 
occurs when the user requests to respecify the results 
card . 

10101 is typed to confirm usage of disk for results and occurs 
whenever disk is specified on the results card. 
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The following error mesnages are typed under the conditions 

listed. 

E361 is written when the tape is being filed forward and a 
file is encountered with filctype other than zero be- 
fore the requested file is reached and MODE = 0. 

E362 is written when the circumstance for E361 occurs and 
MODE = 1. It is also written when MODE «= 1 and the 
filetype of the file requested is = -1. 

E363 is written if the RESTRT flag is = 1 and the filetype 
of the requested file is not = 1. 

E364 is written when MODE » 1 and the filetype of the file 
requested = 1. 

E365 is written when an EOF is read on the results file. 
This should never occur with valid results files. 

For message texts refer to the User's Manual. 


5. Supplemental Information 

This section deals with the handling of tapes by CIITAPE. 
Input ; 

If a tape is mounted on the device and it is the incorrect 
tape number (as noted from the appropriate status words in 
GLOCOM) , TOPRU is called to unload the tape before the cor- 
rect tape is mounted. If the correct tape is mounted, 

CHTAPE will check for the ring in if MODE = +1. If the ring 
is not in, the tape in unloaded and MOUNT is called to mount 
the tape with the ring in. If the correct tape is mounted, 
CHTAPE assumes that the file number (as recorded in GLOCOM) 
is correct and moves the tape backwards or forwards to find 
the requested file. CHTAPE is a modified version of MMTAPE. 

Output ; 

The tape is mounted with ring in for MODE = +1 and with ring 
out for MODE = 0 . 

The tape is left positioned at the beginning of the requested 
file. When the tape is initialized a TOPRW is used to do 
this. 


6 . Flowchart 


Not applicable. 
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APPEtroiX c 


Example of Structured English Module 


PROGRAM Indsut) 

(* Landsat to LARSYS program •) 


OECLARATXON3 

control. cards ; file; 

end-of-filo ; file- condition; 

error-level f abort : error- level-indicator; 
start, stop : time; 

dunmy^ clock, totcpu, vircpu : corputer- usage; 


BEGIN 

CALL cptimo (dummy, clock, totcpu, vircpu); 

CALL getimo (star t) ; 

REPEAT 

CALL Ir.dint; (• initialize *) 

CALL Indrdr; (* read control card file •) 

IF WOT (tjnd-of- file ON control-cards) THEN 
IF error. level < abort 'HIEN 

CALL Indctl; (• reformat Landsat *) 

CALL Indwup (• wrap-up reformatting *) 

END IF; 

GALL indsum (* sununarize the job 
ENDIF 

C?JTIL t>nd-of-fiIu ON control- cards OR 
error-level >» abort; 

CALL usage(clockr totcpu, vircpu); print computer time used *) 
CALL getime (s top) ; 

GALL lndfl7 (• print fORM-17 •) 


ORIGlNAi. PAGE « 
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CQN/CRT ASCII CHARAC fri S BYTES 1 TC EBCDIC CHAR4CTEKS 
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u 
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IMPUCn IMEblN A A |A-/i 

tsnifi 5S(S55H'tt‘.?ra£issa 

ALUriNfcS INVCKfcC CIHtCHV liV LNCSUP 

I ipl 

C INCRIM 

5 INCSIM 

C INCUtP 

C USAGE 

I ••«••••#•• )4« tAf* •••••••««» 4 4»*«44»44f 4 44*«*«*4«44«« ••••*«• 9 vs* 999 
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C LN.,‘'IL 
C iNi.ASO 
C LVuNEO 
C INTPAC 
t IN,. PAN 
C INCPRP 
C LNuRtS 
C LNC-^CH 
C LNCSfl 
C LNCSUH 
C LNUSUP 
C IN’JfPA 
C INwVAt 
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tel »vt 


O^i 


XUumjP 
PL , • I 
PC4* ii 
IS 

\fini 

|}=s/f 

jlV'lt 

U >•;> 

U 4 f, 

iST 


# lifcM.SAl H,MHMA1MSI» 


U^y f f 

u'r Tctlf 

UNHt py 

\v,w sc 

liNTPV Nt 
itNfrfy £U 


A U^r iS A UIH IHlVt 


SI ul 

M tr 

\ I. wl 


MISM‘| CHsfH IMe wRIlt PRtliCT » 
SMISu imiH AS MRAY IN A^ fL'HHA 
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lAPUMI lUkWARU fUf A^IAPfc 
lAMMPl U^AU A RrCORU ARUM fAPk 
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TFb INPUT fRfcCULNCV. *. 

LCtNTI 161# fREJi UtKIf 

SnilNC tP IHE KEPOkMAM ISC... ^ . 

CCNc# MA4RC# MeRElG# RnSCRU I# SELECT# WRUNI I 


LCmICAI CCNE# MckFLO 
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APPENDIX D 


Image Registration Functional Specifications 


An image registration capability has been determined to be a 
necessary part of the FRIS III image preprocessing software. Image 
registration is general enough to mean grid to brld transformation. 
Thus, while the system is designed to register two coincident Landsat 
scenes, registration to alternate grid systems may be accomplished 
with this software as well. Functional specifications will be as 
follows: 

I. Purpose 

A. Primary: Registration of two coincident digital images as 

two Landsat digital image data sets. 

B. Secondary: Provide for the registration of any known two- 

dimensional grid to another known or defined two-dimensional 
grid. 

II. Input images are assumed to be in LARSYS format. 

III. Checkpoint Acquisition 

A. Manual checkpoint acquisition is possible. 

B. Cross-correlation of two coincident digital images may be 
accomplished by implementation of a numerical integration 
image correlator. 

C. Control may be by set line and column intervals. 

D. Alternate control will be from a set of inputted control 
correlation point locations where a cross correlation is 
desired, i.e., arbitrary point by point correlation. 

IV. Registration transformation 

A. Coefficient determination will be calculated for affine, 
biquad, and bicubic transformation. 

B. Transformations through bicubic will be implemented for 
the registration transformation. 

C. Block registration technique will be utilized, 

1. Optimum rectangular block size will be determined for 
biquadratic and bicubic registrations. 

D. Interiors of all blocks will be registered with an affine 
or linear transformation. 
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V. Radiometric Intorpoiatlon 

A. Nearest neighbor will be the default. 

B. Cubic interpolation will be optimally implemented. 
VI. Output Images will be produced in LARSYS format. 
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APPENDIX E 


Cubic Interpolation Used in the Image Registration System 


The algorithm used in the current image registration system for cubic 
interiJolation of data values is based On a thrid order Lagrange inter- 
polation. The general Langrangian interpolating polynomial for three 
dimensions is: 


P 

mn 


(X,Y) 


where 


Lj^(X) « 


m n 


= E E L. (X)L.(Y)f(X.Y.) 

i=0 j=0 " ^ ^ J 

n i » 

k=0 X.-X, 

, X k 


and 


Lj(Y) = 


n 

n 

j=o 


Y-Y, 


3 X 


j = 0, . . • ,n 


The image registration system uses the above equations with m = 3, n >= 3 . 
Therefore, we need m+l=4 different X^ values and n+l=4 different 
values. The X^'s suid X^'s used are 0,1, 2, 3 and 0,l,2,f'». Then the general 
equation reduces to: 

= Lg(X)LQ(Y)f(0,0)+Lj^(X)LQ(Y)f(l,0) + 

L2(X)LQ(Y)f(2,0)+L3(X)LQ(Y)f (3,0) + 

Lq (X) Lj^ (Y) f (0, 1) +L^ (X) Lj^ (Y) f (1, 1) + 

L2(X)Lj^(Y)f(2,l)+L3(X)Lj^(Y)f (3,1) + 

Lq (X) (Y) f (0, 2) +L^ (X) (Y) f (1, 2) + 

L2(X) L2(Y)f (2,2)+L2(X)L2(Y)f (3,2) + 

Lq(X) L 2(Y) f(0,3)+Lj^(X)L3 (Y)f ( 1 , 3 ) + 

L 2 (X)L 3 (Y) f( 2 , 3 )+L 3 (X)L 3 (Y)f ( 3 , 3 ) 
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where: 

Lq(X) 

(X) 

L2(X) 

L3(X) 


(X-1) (X-2) (X-3) 
(0-1) (0-2) (0-3) 


(X -0) (X-2) (X-3) 
(1-0) (1-2) (1-3) 


= (X-0) (X-1) (X-3) 

(2-0) (2-1) (2-3) 


(X-0) (X-1) (X-2) 
(3-0) (3-1) ( 3 - 2 ) 


X^ - 6 X^ 4-llX -6 
- 6 

X^ - 5X^ 4- 6 X 
2 


X^ - 4X^ + 3X 
__ _ 

X^ - 3X^ + 2X 
6 


and L, (Y)'s have the same equations with Y substituted for X 
D 

and f(X,Y) is the data value associated with pixel (X,Y) . 


Tb save computation time, the L;'s are calcualted according to the above 

equations for specific points} in the (X,Y) grid. These points were chosen 
at quarter pixel intervals as shown in figure 1. The calucalted I<^(X)'s are 



L^(X) 

b^(X) 

1.2 (X) 

1.3 (X) 

X = 1.00 

lO.O 

1.0 

0.0 

0.0 

X = 1.25 

-0.0546875 

0.8203125 

0.2734375 

-0.0390625 

X =r 1.50 

-‘0.0625 

0.5625 

0.5625 

-0.0625 

X = 1,75 

-0.0390625 

0.2734375 

0.8203125 

-0,0546875 

X 5! 2,00 

0.0 

0.0 

1.0 

0.0 


The same table applies for Y=1.00, 1,25,1.50, 1.75, 2.00. 

In the image registration process, an input point A (see Figure 1) is 
approximated to its nearest quarter pixel. To calculate the data value 
associated with A, the Lagrange polynomial coefficients for that quarter 
pixel location are used in the P 33 (X,Y) equation. To further Save on 
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computation, the products L. (X)L. (Y) for all combinations of the quarter 
pixel locations ((1.0, 1.0), (1.25,1.0), (1.50,1.0), (1.75,1.0), (2,0, 1. 0) , 
(1.0,1.25), (1.25,1.25), etc.) have been stored in a table. Then when 
P _(X,Y) is calculated, a table lookup locates the appropriate L. (X)L. (X) *s. 

•5 J 4> 3 

When this algorithm was implemented for cubic interpolation of data values, 
it was determined that the error introduced by this method of using 
discrete intervals versus continuous intervals was negligible. It was 
negligible because the intervals involved were quarter pixels and the 
final data values were integer values between 0 and 255. 


References: 

Multi tenporal Image Registrations of Multispectral LANDSAT Data of 
Finney and Ellis Co.'s, Kansas by Nearest-Neighbor and Third Order 
Lagrangian Interpolation Methods.** Prepared by Charles R- Smith, LARS, 
September 20, 1976. 

Source listing of OVERLA subroutine used in current Image Registration 
System. 
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( 1 , 1 ) 
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( 2 , 1 ) 

. A 
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2 A A 

( 1 , 2 ) 
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( 2 . 2 ) 


3 A 


A 


A 


A 


Figure 1 . 4x4 iData matrix surrounding point 

to be interpolated (point A). Example: 
Since point A is nearest grid coordi- 
nates (1.5, 1.75), the Lagrange coeffi- 
cients for this X and y are taken from 
the table and used in the interpolating 
polynomial. 
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APPENDIX F 


Reformatting Documentation Standards 


Preface 


This guide supplements the LARSYS Standards Report Section III 
Programming Standards. Programmers writing software for the Reformatting 
group should read the LARSYS report as well as this guide; wherever this 
guide conflicts with the LARSYS report, this guide should be followed. 
Programmers should tcike particular note of the paragraphs in the LARSYS 
Standards Report Section HI on Assembler and EXEC organizations and 
comments, and on programming techniques. 

The main enphasis of the guide is on the documentation of program 
source code. Program logic must flow downward, cuid comments must 
reflect that flow. Wiidiin the source code, all global and local variables 
roust be identified in variable description lists. The source code also 
must contain a general description of the algorithm used and input/output 
requirements. Specific coding and commenting practices are recommended 
for improving the legibility of source code. 

This guide contains the following information. 

I. Documentation Outside of Source Code Listings 

II. Documentation Within Source Code Listings 

A. Overall System Stcmdards 

B . Layout of Individual Routines 

C. Comments Within the Body of Routines 

Appendix A Example Control Card Description 

Appendix B Exanple LARS Program Abstract 

Appendix C Example Software System 


Appendix D 


Example Block Data 
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I. DOCUMENTATION OUTSIDE OP SOURCE CODE LISTING 

A. Any program with a control card reader must have a separate 
description of its control cards . The description must include 

all keywords and all paramot.ers with an indication of which keywords 
and parameters are required and which are optional. All default 
values must be indicated. It is also useful to include one or two 
sanple control card decks, For an example of a control card 
description, see Appendix A. 

B. Any program designed for use by non-reformatting staff should 
have a user's guide. This guide should include several example 
user sessions . 

C. Any progreun Using routines that depend on non- trivial algorithms, 
calculations, or data structures must have an abstract. The abstract 
may be for an entire system or for specific subroutines. The 
abstract must describe the algorithms, calculations, and/or data 
structures in sufficient detail for a person unfamiliar with the 
source Code to understand the implementation. For a major progrcim, 
it may be appropriate to have two levels of documentation 
abstracts. One abstract would be directed at the interested user, 
and the other at the programmer responsible for program maintenance. 
For aiN example of a program abstract, see Appendix B. 
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II* DOCUMENTATION WITHIN THE SOURCE CODE LISTINGS 
A* Overall System Standards 

1. Each Routine must flow logically downward. See Appendix C 
for examples of routines that flow logically downward. 

2. The names of all routines for a specific software system 
must have the same three- letter prefix. The last three 
letters should be unique for each routine and represent the 
main function of the routine. See the example below. 


MEAD - main routine for processing a MEAD product. 
MEACC - read MEAN control cards . 

MEAINT - initialise MEAD variables and common 
blocks. 

MEAMTX - set up MEAD scaling matrix 
MEATRA - translate one line of input values into 
one line of output values. 
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3. Use variables for constants. In ilio exati^>lo below, constants 
such as Fortran unit numbers and the buffer sizes are declared 
as variables. «uch a convention facilitaVos program 
maintenance and revision. 

LOCAL variables 


BEAL ♦ « 
INTEGER 


TIME 


BLANK/* •/, 
HEX3F /£3F/. 
IhUNT/12/, 
MAXLC/100CG7, 
TRK7 /'TTRM/ 


LOGICAL * ^ ICFLG 
INTEGER * 2 L AROAT I 50C0 1.f 
LOGICAL ♦ 1 IhaUFI lOOs®) , 


FlLNl/21/. F20NT/22/. F3UAT /23/, 
HEXPF /ZFF/, INBCKT /lOOfi/* 
NAXChN/3/i fAXIN/500/f 
Nq/*^C */f CUT ID (200 If CUTLNT/ll/f 


ROLL /Z7FFF/ 


ZERO/ZOO/ 


4 4 444 4*4 4 44<>*4'4*44444>4'4«4«4 4*44 4>4c4<4*4:44i44>«« 444144 4444444 41 


LOCAL VARIABLE DESCRIPTICNS 
BLANK THE CCNS1ANT BLANK. 

FlUNT DISK LNII WHERE FIRST TAPE FILE IS TRANSFERRED. 

F2UNT DISK LNI1 WHERE SECCND TAPE FILE IS TRANSFERRED. 

F3UNT DISK LN IT WHERE THRIO TAPE FILE IS TRANSFERREC. 

HEXFLG EQUALS T(E ID FLAG FOR THE INPUT TAPE (DEPENDS ON 
FORMAT OF INPUT TAPE). 

HEX3F CONSTANT EQUAL TO 3F HEXIDECIHAL. AN INPUT RECORD IS 

AN ID RECORD IF THE FIRST BY IE EQUALS HEX 3F (7 TRACK FORMAT) 
HEXFF CONSTANT EQUAL TO FF HEXOECIFAL- AN INPUT RECORD IS 

AN ID RECORD IF THF FIRST BYTE ECLALS HEX FF (9TRACK FORMAT) 
INECNT NUMBER OF BYTES IN AN INPUT RECORD. 

INUNT UNIT NUMEER OF INPUT TAPE. 

MAXCHN MAXIMLM NUMBER OF DATA CHANNELS THIS ROUTINE CAN HANDLE 

MAXIN MAXIMUM NUMBER OF DATA VALUES IN CNE INPUT RECCRC. 

BYTES ALLOWED IN GNE LINE CF LARSYS DATA. 
OUTUNT UNIT NUMEER FOR OUTPUT TAPE. 

Nc‘ " constant equal to *NC*. 

TRK7 constant EQUAL TO *7TRK*. 

ZERO CONSTAN*^ BYTE EQUAL TO CC HEXIDECIHAL. 


Example 2 

In the aU)ove example, local variable descriptions have been provided 
only {'Or the "constant" variables. See the exanple software system 
in Appendix C for descriptions of all local variables . 

4. Block commons must be named and they must have variables 

listed in the. order: „ 

REAL * 8 

REAL * 4 * 

INTEGER * 4 
LOGICAL * 4 

LOISTCAF. * 1 



ooo or>ooo ooo 


33 OF POOR QUALITY 

within each type of variable, the variables must be listeci alphabetically. 
Largo common blocks must be spaced for legibility. 


VAKIABL6 NAMES FOR AGRONaMIC ID AND FOR SOUS IS 


COMMON /IDNAME/ 

AIIEt 

AZIR, 

AZVI, 

HAPR, 


BRLE 

COMMON /IDNAHC/ 

CARU» 

CAIN, 

CLCO, 

CLTYIA) 

f 

C0B2 

COMMON /IDNAME/ 

COMM(37I 

,DACO, 

DADA, 

DA PL, 


DfiBL 

COMMON /IDNAME/ 

DOFR, 

DQGL 





COMMON /IDNAME/ 

OBSTt 

DO TO, 

DDLE, 

OBVL, 


DEED. , 

COMMON /IDNAMl/ 

DENA(Z) t 

OERA. 

OIGR, 

D1 IN, 


DQFl(2> 

COMMON /IDNAME/ 

OQF2(2) , 

DQP3I2I • 

DQFA(2) , 

OGF5(2) 

f 

DCF6( 2) 

COMMON /IDNAME/ 

0QF7(2) » 

DRCL, 

EPCl, 

EP02, 


EP03 

COMMON /IDNAME/ 

EP04, 

2P05, 

EPC6, 
EXNAU) , 

E'?07, 


EP08 

COMMON /IDNAME/ 

EP09, 

EPIO, 

EXNU, 


FANA( AJ 

COMMON /IDNAME/ 

FIAC, 

FINU, 

FI VI, 

FLLU2J 

f 

FOCA 

COMMON /IDNAMl/ 

FRBI, 

FRCO, 

GMCS, 

GRLE, 


HAWI 

COMMON /XDNAME/ 

HEIG, 

HERF, 

HI SC, 

HORI (2) 

f 

1LLU( 2) 

COMMON /IDNAME/ 

iNlNt 

INNAI4I , 

INST, 

JUDA 


LF7 

COMMON /IDNAME/ 

LAID, 

LEAR, 

LEPL, 

LF(6) 


COMMON /IDNAME/ 

LF8, 

LOCA(4l , 

LODA, 

LOLA (2) 

f 

L0L0(2» 

COMMON /IDNAME/ 

LOSQ, 

KATUIAI • 

MDDA, 

FOFI (A) 

f 

FOLA 

COMMON /IDNAME/ 

MOST, 

MUCQIAI , 

NMAT, 

NUDE, 


NUSA 

COMMON /IDNAME/ 

NUSG , 

OBNU, 

OTST, 

PECL, 


PEGR 

COMMON /IDNAME/ 

PESA, 

PE SI. 

PHFR(2) , 

PHRO, 


PHSE( A) 

COMMON /IDNAME/ 

PLCO, 

PLDAt 

PLFC, 

PLNU, 


PROW 

COMMON /IDNAME/ 

PRIN(4) 

RATE 





COMMON /IDNAME/ 

RECA, 

RE DA, 

RE HU, , 

RENU, 


RCDI 

COMMON /IDNAME/ 

ROWI , 

RUSE, 

SAGR, 

SCRA, 


SCTYI A) 

COMMON /IDNAME/ 

SENA(^) , 

SENU, 

SPECCA) , 

STGO(IO) 

,SUCO( A) 

COMMON /IDNAME/ 

TALE, 

TATE, 

TAWI, 

TCRl, 



COMMON /IDNAME/ 

CunmUN /iu»N«nc^ 

COMMON /ICNAME/ 

TEXT(4) , 

4 « W 

WAQA (4) , 

TIOA, 

TSWT, 

UNCA, 


VARU A) 

WBTE, 

WEED, 

MIDI , 


WISP 

COMMON /IDNAME/ 

VEDA, 

YELD, 

YELE, 

ZEIR, 


ZEVI 

VARIABLE NAME* EXCLUSIVELY FOR SOILS ID 




COMMON /IDNAME/ 

ACT ! , 

ALUM, 

ASHOI2) , 

AVPH, 


AVPC 

COMMON /IDNAME/ 

BA SA , 

BUDE, 

BUFH, 

CAEX, 


C^LC 

COMMON /IDNAME/ 

CHRO, 

CLAY, 

COCO, 

COIN, 


CQPA 

COMMON /IDNAME/ 

COSA, 

CQSl, 

CSNU, 

ELCO, 


ELNU 

COMMON /IDNAME/ 

EPll, 

EP12, 

EP13, 

ERFA, 


ERGS 

COMMON /IDNAME/ 

EXAC, 

FINE, 

FI SA, 

FISI, 


FSAN 

COMMON /IDNAME/ 

GRGRI2) , 

HUEl, 

HUE2, 

IRON, 


LI IN 

COMMON /IDNAME/ 

L IL I , 

LISH, 

LUF(6) , 

M AGN , 


FANG 

COMMON /IDNAME/ 

MESA, 

MI CL, 

MOTE, 

MCZC(2 J 

Y 

FSAN 

COMMON /IDNAME/ 

MSNU, 

OMOD, 

OKCA, 

ORDR, 


PAF.A 

COMMON /IDNAMJ/ 

PASI , 

PHYS, 

PLIN, 

PLU , 


PCTA 

COMMON /IDNAME/ 

SAND, 

SAPO, 

SHLI, 

SHRA, 


SILI 

COMMON /IDNAME/ 

SILT 






COMMON /IDNAME/ 

SLOP, 

SDDI, 

SOEL, 

SPGR, 


STAB 

COMMON /IDNAME/ 

STLN, 

SUBQ, 

SUDE(IO) 

,SUNA(AI 

9 

TERE(2» 

COMMON /IDNAMl/ 

UN IF, 

VALU, 

VC SA, 

VFSA, 


VCSH 

COMMON /IDNAME/ 

WACO, 

WAPH, 

WI ER, 

YEAR 




iNTERMcDIATE VARIABLES USED IN CALCLLATION CF ID VALUES 
REAL * A VARIABLES 


COMMON 

/IDNAME/ 

METROK, 

XFRCO, 

XPLCO 




INTEGER 

♦ A VARIABLES 






COMMON 

/IDNAME/ 

AGOG , 

BIGPLT, 

FWR, 

CRG, 

HEAD 


COMMON 

/I DN AM E/ 

MODE, 

HOZ, 

ORD, 

SI OE t 

SUBR 


COMMON 

/ IDNAME/ 

SURF ST, 

SWING, 

TE FR, 

TEX, 

INTBUF(50 

) 

REAL * 

A FETFOW 

, XFRCO, 

XPLCO 






Example 3 

Although the conmion block above rioe not list the variabl'in in the or-ii 
IMTEOER, LQGI&'vL, it is a qoocl oxainplo of spacing i'or lealbi l.i“y 
viriables vire .irrangud by usag'.' in this comitvjti block) . 
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ORIGINAL PAGE IS 
OF POOR QUALITY 


Common block variables must bo doscribod in a BLOCK DATA 
routine or in an initialisation subroutine. The variable 
descriptions must bo alphabetic. See Appendix D for an 
example. 

5. Do not use Fortran entry points unless the use of them 

is clearly the best solution to an inplementation problem. 

6. Information and error messages should he informative to 
the user as well as the programmer. Each message must 
include the name of the routine printing the message. 


c 

*cLSE ERROR 

4200 

OK a .FALSE. 

WRITE (TYPWTR, 94210) 1* ID(STRESS(I ) 

WRITE (PRNTR» 94210) I» I DISTRESS! I) ) ,,^^ . 

94210 

FORMAT!' EOOAO STRESSI't 12, ») DOES NOT EQUAL', 

1 

• Nf Y , OR BLANK. 

2 

• INSTEAD IS SET TO !', A4, ')', 

3 

4X, MXTKA)') 


Example 4 


It may be numbered either sequentially (1 to n) or for the 
labeled Fortran statement nearest the message in the code. 

In the example above the message is numbered sequentially. 

In the example software system in Appendix C the messages 
are numbered for labeled Fortran statements . 

7. Labels for code statements must be assigned in ascending 
order within the body of each routine. For examples see 
Appendix C. 

0. Labels for format statements must be assigned in ascending 
order within the body of each routine. The FORMAT labels 
should be sufficiently different from the code labels that 
they stand out. For example, code labels in a routine could 
range from 100 to 900 and FORMAT labels from 9100 to 9900. 

The FORMAT statements may be intersperssd with the executable 
code or they may be just before the END statement. However, 
within one routine, they must be either all interspersed or 
all at the end. The software system shown in Appendix C is 
an example of FORMAT statements interspersed with executable 
: code. ' 
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9. Do not use unnecessary EQUIVALENCE statements, llowevor, 
there are some data structures for which EQUIVALENCE 
statements are necessary. For example, a LARSYS ID record 
contains real data values and integer data values. In order 
to correctly access both data types, the ID record must be 
declared as: 

REAL * 4 RID (2000) 

INTEGER * 4 ID (200) 

EQUIVALENCE (ID(1) , RID(l)) 

10. Use standard LKRSYS and Reformatting routines whenever 
possible. For example, often used LARSYS routines arc 
CTIWRD and BCDVAL (for interpreting control cards) , and 
often used Reformatting routines are IDRITE and EOT (for 
mounting LARSYS data tapes, writing ID records, and writing 
end-of-tape records) . 

11. Document all revisions to routines by adding your name and 
date to the comments. Include a version number if 
appropriate. If the revision is appropriate for only a 
special application, add a comment near the revision 
comment stating exactly what the special applications is . 


C 

C VmiTTEN 07/19/79 BY CATHERINE KOZLOWSKI FOR FY70 

C SRST CONTRACT 

G 

C REVISED 11/20/79 BY CATHERINE KOZLOWSKI FOR FY79 

C SRST CONTRACT 

C 


Example 5 


12. Indent (horizontal) and space (vertical) the source code 
to improve readability and/or logical flow of each routine 
See the software system in Appendix C for examples. 


-? 

i 

§ 

{j 

I 
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ORlGINAt. PAGE IS 
OF POOR QUALITY 


13. When reading or writing a long string of variables, space 
the variable names the same in the READ/WRITE statement ns 
in the FORMAT statement. 


C**<t'*** 

C 

C READ 
C 

C ♦****« 

200 

1 

2 

3 

5 

C 

9200 

1 

2 

3 

C 


1 

2 
2 

4 

5 

'9201 


« « f * « i» 1 4ii«i « ^ 4< « 4< 4 ♦ 4> 4t 4i «M(c ♦ 4 ♦ « « 4 4> « « « # i<u» # ♦ 4»i)t « « ♦ 
AGRONCMIC RECORD SHEET NUMBER 2 CF THE GROUP OF 7 

ID(GRLE)f 


4i 4:44i4t 44>4t4>*^<‘ 44t<c4[4i4i4(4t i»ifi4[<c«4i4(4t4'4t4‘4< 

RcAC (AGSHE, 9200, EN0»110) 
AG0C2, PAGE2, RIO(HEIG), RT 
lO(YELE), IB(BRLE», XPLCO, 
METROW, ID(PEGR), RIOIDDGL5 
RIO(CBbU, RID(OBST), RI0(0 
KIO(FRBI), BIOPLT, RIOiLEAR 


CILEPU , 

XFRCQ, 

, RIDCDBYU , 

BFR) , RIOCDBTm, 
), ID(PLFG) 


FORRAim, II, F3.0, IX, FA.l, IX, 312, 
F4.0,F3.0, 

F4.0, IX, 12, IX, 5F8.0, 

2F6.J, ll, F5.0, IX, I2J 


PTRA = PTRA - I 
KEADIAGSHE, 9201, 6ND«110) 


BLKID(FEIC), 
BtKID( BRLt) , 
BLK10( CBGL) , 
BLKIDC CBFR) , 
BLKID( PLMO) 


RLKIDILEPLJ 

BLKIDCPLCOJ 

BLKIDIOBYU 

BLKIDIDBTO) 


BLKID(GRLE) , 
eLKID(FRCC) , 
BLKlOfOBBU , 
BLKIDIFRBI) , 


FORMAT (T5, 
IX, 


A3, IX, A2, TIA, 3 
5UX,A4), 2(2X,A4) 


A2.,IX, 2A3, T32, A2 , 
f T76, A2, IX, A2I 


BLKIDIYELE), 

BLKID(PEGR), 

BLKIO(OBST), 

BLKIO(LEAR), 


Example 6 

14. If possible, use the following convention for FILEDEFing 
and assigning tape units; 

FILEDEP ll TAPI 
FILEDEF 12 TAP2 
FILEDEP 13 TAP3 
FILEDEP 14 TAP4 
FILEDEF 10 TAPS 

where Fortran unit 11 is the output tape and units 12-14, 
10 are input tapes. 
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15. I$cveral suggestions about labels and CONTINUE statements 


a. It is easier to revise routiije if each DO loop has 
its own CONTINUE statement. 


DO 120 K » 1, 20 

DO 100 J « 1, 3 • 

ARRAY (J,K) = J +K 
100 CONTINUE 
126 CONTINUE 


Example 7 

b. It is easier to revise a routine if all of its non- 
FORMAT Ictbels are on CONTINUE statements. 

16. Debugging convention 
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B, Layout of Individual Routines 


C routine name 
C 

^ ★★★A #1^ ***★#♦★*★* # <f #1^ it if it it it it it it it it it it it it it it it it it it it, it it it it, it it it it it it 

Q routine name one-^lino description 
C 

C WRITTEN date BY name FOR CONTRACT name or number 
C REVISED data BY name 
C 

SUBROUTINE name 
C 

IMPLICIT INTEGER * 4 (A 25) 

c ■ 

C detailed description 
C 

C special features and/or limitations 
C 

c input 
G 

C output 
C 

C subroutines used (include one-line description of 
each subroutine) 

C 

COMMON /name/ declarations 


COMMON / name/ declarations 
C 

Qilr ★★★i^**>****** it:ir_r^-it it it it it it it it it it it it it it it it it it.it it it it it it it.it it,it it,, it it it it it it it it it it it it it it it 

c 

C LOCAL VARIABLES 

C 

local vatiablQs declarations by type^ then alphabetic 
(include parameters as necessary) 

G 

C local varisble descriptions including pararoetersr listed 
alphabetically 
C 

body of routine 
END 


Example 8 

All routines should follow the neneral format outlined above. 
See Appendix C for a complete system following this layout. 


ORfGINAL PAGE IS 
Qf POOR QUALITY 

'—I ij 



nr>or>oor»r>r>r> nioorjo r^rsriorirtor^or^oooonrsorJ I 


ORIQINAI RACE IS 
OF POOR QUAUTY 


Xf Tho first; sdvsral linos of U»e sourca eodt> ahould idonttify 
tho roufcino. 


SPCSCN 

SPCSCN WEFCRH^TS CNE SPECSCAN tape Tb CNE LARSVS BUN. 

WRITTEN 02/lA/7< BY CATHERiNE KOZtOVSKI FCR SRGT PYT9 CCNTFACT 
REVISED CA/0A/T< DY CATHERINE KCZiOVSKI 
REVISED CT/02/TV BY CATHERINE KQZLOhSKI 

»v4*44444f*4**4444444AA4A«4»««4»4i4A«^A«444*4 4f «i«»*»4 444A 444AA 444‘^'** 


Exawple 9 


2. After tlie IMPLICIT INTEGER * 4 statement, there should be 
a detailed description of tho routine. 


SPCSCN 

THIS PROGRAM AND ITS SUERQUT! 
OR 9-TRACK 0CO API SPECSCAN TAPE 
D/ITA^RUN. THE (RI6INAL SPECSCAN 
WRITTEN HAS RECIIVED FROM RCHERT 
SERVICES INC. (TEXAS OPERATICNS. 


AND ^ ITS SUERQUT INES RE FORMAT A T-TRA 
API SPECSCAN TAPE TO A 9-TRACK 1600 0 


ES REFORMAT A T-TRAGK IMCDH 3) 

TO A 9-TRACK 1600 OPI lARSYS 
TAPE FCR WHICH THIS SCFTWARF WAS 
A. GOOCDING. TOCHNICCLCR GRAPHIC 
LYNQCN 0. JOHNSON SPACE CENTER, 


P.O, BOX 5e863f HOUSTON* TEXAS TTCSET. 

THE INPUT TAPE HAS CNE OR MORE FILES* EACH FILE CCRRBSPCNC IN G TO I 
CHANNEL OF DATA ON THE LARSYS TAPE. ALL RECCRDS CN THE INPUT TAPE 
ARE ICOa QYTES^tONG.^ THE FIRST INPLT RECORD OF EACH FILE MAY 
BE AN ID RECCRO — IF IT IS, THE FIRST BVIE EQUALS HEXICECIMAL 

RECQRC I.S SKIPPED CURING PRCCESSING OF CATA. 
IT IS ASSUMEC eiCH FILE HAS THE SANE NUMBER OF RECORDS AND, 

IF ONE FILE HAS AN ID, THEY ALL HAVE ID PECCROS. 

IT^IS ALSO ASSUMED^THAT THE ONLY SI IE OF ONE SPECSCAN INPUT 
RECQRC IS 1000/ BYTES. ONE LINE OF SPECSCAN INPUT MAY 

BE SEVERAL INPUT RECORDS LCNG. 

CONTINUE 

THE PROGRAM R6QLIRES ONE TEMPORARY DISK AND THO TAPE DRIVES. 

THE EXEC CACLLA1ES THE AMOUNT CFIEMP SPACE NEEDED FOR THE DATA 
TC BE TRANSFERRED. THE INPUT TAPE CRIVE IS ASSIGNED UNIT NUMBER i; 
IT MAY BE A T OR 9 TRACK DRIVE. THE QUIPUT TAPE DRIVE IS ASSIGNED 
UNIT NUMBER n IT IS A 9 TRACK DRIVE. 

C C* N T I is ^ C 

THE PROGRAM FIRST TRANSFERS THE INPUT TAPE FILES TO DISK. THEN 
IT SETS UP THE tARSYS ID RECnRO- INPUT DATA IS REFCRMATTEC LINE 
BY LINE.- .„EACH |NPUT_^TINE GCES^THROL^^^ FCLLCW I NG PRCGESS INGD 
1) INPUT FUF CHANNEL N IS READ FROM DISK N INTO A TEMP BUFFER. 
21 THE DATA IN^THETEMP^BjJFFER IS RDFORMATTED FRCM 2 BYTES 

PER VALUE TO 1 BYTE PER VALUE. THE DATA IS INVERTED (BLACK 

NECESSARY* THE DATA IS ALSO 

• FLIPPED LEFT TO RlGHT- 

31 THE DATA IS^MOVED^TC A LARSYS-FOPMAT CATA LINE 
AND WHITEN TO TAPE. 


THO TAPE dr IVES. 

NEEDED FOR THE DATA 
ASSIGNED UNIT NUMBER 12 
TAPE DRIVE IS ASSIGNED 


example 10 


In tlvo above example, special features and limitations of the 
routine have been noted, Snecial fi-atureii are X) the input can 
be on either a 7-hrack or 9“ track tape, anti 2) ihe data uan ha 
flipped ioft to riqht. LimitaUionn are i.) if one input liie huit 
an id record, all input files must hvivn ids, afttl i) the KPU’ i.;,' 
requires two tape drivoa and one temporary Msk, 
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3. Input requirements must bo specified. 


C 

C 

c 

c 

c 

c 


THE INPUT IS AN AfRAV OF DATA VAlUES IN SFECSCAN TAPE 
FORMAT. 

EACH DATA VALUE IS ASSUPED TO 06 ONE 3-BIl FIELD IK 
AN 8-BIT BYTE AND ONF 6-RIT FI6LC IN AN 8-BIT BVTEt 
THESE TWO FIELDS REPRESENTING CNE DA1A VALUE RANGING 
FROM 0 TO 5 1 1. 


Example 11 


4. Output from a routine must be described. 


C 

C 

C 

c 


THE OUTPUT 15 AN ARRAY CF DATA VALUES WITH EACH 2 BYTES 
REPRESENTING ONE 8-8 IT DATA VALUE I THE FIRST BYTE IS SET TO 2ERC 
AND THE SECOND BYTE CONTAINS THE DATAI. CUTPtT VALUES RANGE 
BETWEEN 0 ANC 255. 


Bxcunple 12 


5. The source listing must include all non-system subroutines 
called. 


c 

THE NON-SYSTEM 

SUBROUTINES LSEO AKEC 

c 

EOT 

VRITES END-CF-TAPE RECCRC N CUTPUT TAPE. 

c 

GTDATE 

RETURNS TODAYS'S DATE IN CFARACTER FORMAT. 

c 

lORITE 

MOUNTS OUTPLT TAPE AKO WRITES OUTPUT RUN ID RECORD. 

c 

MOUNT 

fOUNTS INPUT TAPE. 

c 

MCVBYT 

MOVES BYTES FROM INPUT BUFFER TC CUTPUT EUFFEP. 

c 

SPCOAT 

IRANSLATES DATA FROM A 9-BlT FORMAT TO AN 8-BIT 

c 


FORMAT. 

c 

SPCSAM 

CALCULATES IHE NUMBER OF SAMPLES PER CHANNEL IN THE 

c 

OUTPUT. 

c 

TAPOP (EFTRV POINTS IQPEF, TCPFF, 1 

c 

c 


TOPRO, TOPWR) PERFCRM.S TAPE I /C FUNCTICNS- 

c 

c ■ ■ ■ ■ ■ " 

f. 


Example 13 
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6. Al,'*, local variables must b® declared (as necessary) and 

described. 


c 


INTEGER ♦ ‘s BLFCNT 
1 ZERO /O/ 


444«4444 

/5CA/, f-AXDAI /500/, KCADAT /<♦/# RLIf IT /5/* 


INTEGEI!) ♦ 2 BIFFER(50AJ 
LOGICAL ♦ 4 IIFLG 


LOGICAL ★ I 
EQUIVALENCE 


lABUFt lOCE) 
(EUFFER, INBLFI 


C4 4 4* 4 4 444¥^4444444 44444 444444 <<44444>*<44< 444(4 444 4 44 44 4 4 4 44444444444444444 

c 

LOCAL VARIABLE DESCRIPTICNS 


C 

C 

C 

C 

C 

C 

C 

C 

C 

C 

c 

C 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 


ACJUST TEMPORARY VARIABLE LSED TO ADJUST SA?>PLE CCUNT TC BE EVENLY 
DIVISIBLE BY A. 

BUFCNT NCMBER OF ELEMENTS IN INPUT BUFFER. 

BUFFER INPUT BUFFER IN INTEGER ♦ 2 FORMAT. 

DISP DISPLACEMENT INTO INPUT BUFFER. 

ICFLG FLAG INDICATIANG WHETHER FIRST INPUT RECORD OF THE FILE IS 
AN ID RECORD. IF IDFLG IS SET, FIRST RECCRD IS AN ID. 

INEUF INPUT BUFFER IN LOGICAL I FORMAT. 

LSTVAL LAST CATA VALUE IN INPUT BUFFER. 

MAXDAT MAXIMUM NUMBER OF DATA VALUES POSSIBLE IN CNE INPUT RECORD. 

CONTINUE 

NON-DATA VALUES IN INPUT BUFFER. 

CONSECUTIVE RECORDS READ WHEN SEARCH FGR ZE 


NCNCAT 

NREAD 

NSAMP 

PPEVAL 


LARSYS 

SEARCH 


NUMBER OF 
NUMBER OF 
VALUES. 

NUMBER OF SAMPLES PER CHANNEL THAT WILL RE IN 
PFEVICUS DATA VALUE IN INPUT BUFFER. USED TO 
BACKWARDS IN INPUT RECORD. 

RLIMIT UPPER LIMT ON THE NUMBER OF CONSECUTIVE READS TC 
BEFORE TERMINATING SEARCH FOR ZERC DATA VALUES. 
TOTAL RUNNING TOTAL USED TC CALCULATE NUMBER OF SAMPLES. 
UNIT DISK UNIT FROM WHICH TO READ INPUT RECORDS. 

ZERO THE CCNSTANT ZERO. 


flO DATA 

cutpuT. 


PERFORM 


(; 444444 44 44*4 44 4 444 444 4 4444444 44444444*4444 4 444 4 4 44 4 4 44 44444 4444 44444444 
C4 44 4 4444 4444444 444444444444444 444444444 444 444 44 44 44 4 4' 444 44 44444 44 4 4 4444 

e 


Example 14 
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C. Comments Within The Body of a Routine 

1. Highlight coroments that describe large sections of code. 

Sec Appendix Q for examples, 

2, Comments by themselves should describe the flow of the 
routine in sufficient detail so a reader can understand the 
routine without looking at the code, 

3, Inobvious progratiming "tricks'* must be explained in detail 
including the reason for the trick. 

4. Specific suggestions; 

a. Comment a control card computed GO TO so that it is 
apparent which label corresponds to which key word. 


c 

r 

IMPLICIT INTECBR 4 4 

(A - ZJ 




INTEGER t 4 

KEYLST(7) 





U 

i 

r 

OATA K6YLST 
L 

/ •♦INP* , 
•ENOS 

•RcFU't 

•-C0H'/ 

MNPL*f 

•SCRAS ‘OUtP* 


C 

r 

DATA KEYS! 

/7/ 





U 

c 

r 

CALL CTLWRCIC/RD, COL 

• KEYLST 

, KEYSZ, 

CODE, READIN, 

ERROR) 

Vt 

c 

c 

1000 

2000 

3GC0 

4000 

5000 

6000 

7000 

♦ INP 

GOTO (1000* 

REFO 
<000 r 

INPL 

3000, 

SCRA 

4000, 

CUTP EhO 

50D0, 6000 « 

-COP 

7000) 

CONTINLE 

CONTINUE 

CONTINLE 

CONTINUE 

CONTINUE 

CONTINLE 

CONTINUE 

STOP 

END 
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CODE 



D a O U O D u o o o 


Common t logical peogeam stifuctutfos with KfeatomnUs 
such asi 


WlILE NOT END'^OP-PII.'E PROCESS DATA 


REPEAT LINE PROCSSSINC UNTIL END-OP-FILE 


IP GOOD DATA THEN PROCESS IT 

ELSE PRINT ERROR MESSAGE 
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INTRODUCTION 

This $uide Is intend^ to serve as a handy reference for new (or infrequent) 
Users of the LARSYS software available at Purdue/LARS, and has been divided 
into two sections. The first section describes the sequence of commands 
required to access the Purdue/LARS computer* create input files for the 
LARSYS processors, execute the LARSYS job and receive printer output. Sec- 
tion II briefly discusses the LARSYS processors used in an analysis sequence, 
with examples of setting up the control card files and executing the jobs. 

Before using this guide, the new LARSYS user should witness a demonstration of 
the terminal equipment, the procedure for accessing the Purdue/LARS computer 
and the steps Involved in executing a LARSYS function. This person should 
also know who is available at his location to answer questions and assist 
with unexpected problems, 

The new analyst should also have some background in remote sensing, such as 
is presented in the monthly LARS Short Course on "Numerical Analysis of 
Remote Sensing Data" or minl«ally, by reading the LARS Information Note 
110474, "An Introduction to Quantitative Remote Sensing." 

This may be followed by an overview of the LARSYS processors and their capa- 
bilities. Brief descriptions can be found in the "LARSYS User's Manual," 
Volume 1; Sections 1, and 2.1 through 2.4. More detailed descrlptionu of 
each processor are located in Volume 2 of the "LARSYS User's Manual" and 
may be reviewed as the processor is used in the analysis sequence. 

The general steps required to access the Purdue/LARS computer and execute 
a LARSYS processor are flowcharted below. The letters refer to the part 
in Section I where that step is discussed, not the required sequence. 
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Section I 

Procedures for Aceeseibg LARSYS 


A. LOGON AND INITIATE THE LARSYS SYSTEM 


In order to access the LARSYS system, It Is necessary to have a computer 
ID and a password. If you do not jknow what computer ID you are to use, 

check wit h . The initial procedure for accessing the 

computer at Purdue/LARS from a typewriter termlpil is called "logging-on'* 
which is illustrated below. Before logging on locate the Attentlon(ATTH) 
or Break (BRK or BREAK) key on your terminal. Pressing this key slgncls 
to the computer you are ready to gain access to the system. Also locate 
the RETURN (or CR) key, which you will press each time you have completed 
typing a line. The command "l lsdv370" initiates the LARSYS system. 

Lines to be entered by the user are outlined with boxes. The > means the 
keyboard is unlocked and waiting for user input. 


VM/370 ONLINE ^ — — (PveBB BREAK key) 

I .. _ , 

l>logon ,1ax I *s — (Subatitute youv ID fov 'Jax ') 


ENTER_PASSWORD; 
|>XXXXXKXXl 


ENTER NAME; t>8chwingendorfi 

LOGMSG - 08; 37:18 EST'TiONDAY 01109119 

* YOUR OPERATORS THIS MORNING ARE ROSS AIKEN AND 


GREG RICHARDSON 


LOGON AT 09 !48;54 EST MONDAY 07/09/79 
l>i ladv370 | 

DEVELOPMENTAL LARSYS READY; 

SYSTEM IS BEING INITIALIZED... 


... LARSYS IS READY FOR YOUR FIRST COMMAND 
T-0.40/1,07 09:49:48 


At this point (after a message beginning with "T»" and a ">") the system 
will accept any of the LARSYS commands listed in the reference file listing 
at the back of this notebook. We will discuss the ones you will use most 
often. 


Note: Character delete - If you happen to make a typing error, you cSn 

type the 0 to "erase" the previous character(s) 

c.g. i lad@@sdv370 
would be interpreted by the computer as 

i lsdv370 

Line delete - If you need to "erase" an entire line, use the C and 
the computer will ignore what you have already typed on that line. 
CP begin - If the letters CP are typed unexpectedly, you will need 
to type "begin". This can happen if you try to type a command 
before the ">" appears or if there is noise on the line. 
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B* PREPARE CONTROL CARD FILES 

To use LARSYS, a person musC first; decide which LARSYS processor Is Co 
be executed» fttSsi? chon create a control card file containing the necessary 
information for that processor. To help the user know what to put Into 
a control card file, lARSYS maintains lists or menus (called REFERENCE 
Files) of all the possible control parameters for each processor* A 
composite list of all processors, including Initialization functions and 
control commands t also exists. For your convenience the list has been 
printed and Included in this notebook. These control card files are 
"shown'* to the LARSYS software system on cards, from disk files, or 
Interactively from a typewrleer terminal. In these examples, we will 
make use of disk files. 


Associated with your computer ID Is a private disk area on which you can 
store one or more flics of information, such as control card files. 

Before discussing the usual processors used In an analysis project, we 
will look at how you can enter a control card file onto your disk storage 
area. You will repeat this process for each LARSYS processor you run. 


A typical sequence, then, might be as follows: 1) determine the desired 

function, such as wanting to produce a grayscale map, 2) from experience 
or by reviewing the function of each processor In the "LARSYS User's 
Hanual", determine the processor that can perform the desired function, 
(for example ®T,CTUREPRINT will produce a grayscale map) , 3) by reviewing 
the control card list (provided at the back of the notebook) for the 
selected processor, write out the keywords and control parameters neces- 
aary to execute the processor, and 4) enter the keywords and control 
parameters into a disk file. Now let's look at how to obtain and enter 
parameters into a control card file. 

Having completed the steps from Section I for logglng-on, we select the 
LARSYS processor IDPRINT, to execute. This processor produces a one-page 
GET listing of identification Information for your data. Use the GET command 
and the first three letters of the processor's name, (In this case IDP) 
to obtain a skeleton control file for IDPRINT. 


>get idp I 

THE FILE — IDP CC — HAS BEEN COPIED TO YOUR PRIVATE DISK. 

IT'S CONTENTS 

-RUNTABLE tA file has two names - only the first 

DATA was needed for the GET oomand. See 

RUN (XX), TAPE(YY), FILE(ZZ) Note at end of this section.) 

END 

*IDPRINT 
PRINT RUN(XX) 

END . , . ''i-... ■ 

EDIT: 
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EDIT As you con oeo from Che above mesooges, Che file named IDP GC is copied 
onco your disk oCoroge b^’coi iCs conCcnCs ore Cyped, and your cpmpuCer 
ID enCers che Edic environmenC . This means Choc you can oncer a variety 
Edic commands which will add, change or deleCe lines from Chis control 
card file. 


In order Co make changes Co Che file, che user musC move to the line Co 
be changed. Four EdiC commands help you posiCion yourself in Che file. 
These are: 

TOP (point to tha Top of the file) 

BOTTOM (point to the taet line of the file) 

UP n (mote up ^n' linee in the file) 

NEXT n (mote dom 'n* linee in the fi)le) 


TOP poinCs you Co Che place before Che flrsc line of che file, BOTTOM 
moves Che poinCer Co che lasC line of Che file and UP and NEXT move Che 
poinCer one or more lines wichin Che file. When Edic is firsC enCered, 
you are ac Che spoC jusC before Che firsC line of che file. If you Cype 
NEXT you will be ac Che firsC line of Che file. Noce ChaC che compucer 
Cypes ouC che line you are on. 


I >nexC I 

-RUNTABL E 
|>nexc 2 1 

RUNfXxV . TAPE(YY), FILE(ZZ) 
-RUNTABLE 


Now lec’s look aC some commands Co make changes Co Che file. Four commands 
you can use are: 


DELETE n 
CHANGE .XXX.YYY. 

REPLACE ’new line’ 
INPUT ’new line’ 


(delete *n' linee from the file) 

(Change the letter e 'XXK^to the lettere 
'XXV in current line) 

(replace current line with 'nwline') 

( ineert 'new line ' after the current line) 


One ocher command, TYPE allows us Co verify which line we are on. 

TYPE ( type the current line of the file) 

Remember ChaC we are currently aC Che flrsC line of che file, which is Che 
line -RUNTABLE. We decide ChaC Che firsC four lines of Che file are noC 
needed and cype DELETE 4 . Using Che TYPE command reassureB us We are no 
longer ac che line -EUNTABLE (because IC was removed from che file) and are 
aC Che new firsC line of Che file, *1DPRINT. 


hiclece 4 

>Cype 

*IDPRINT 

We proceed co Che next line of the file and use Che CHANGE commanci to 
supply a run number in place of ’XX’ . 


^00 
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PRINT RUN (XX) , 

(>change ,xx. 760201064 
PRINT RUN(7602Q106) 

We decide to Input a comment line at the bcglnninft (TOP) of the file 
ualng the INPUT command. (TOP ntands for Top Of Kile) 

TOF; 

I > Input ""CornCTent teat comment line | 

To replace this entire line with a new comment, the REPLACE command 
can be used. 

>replace -comment print id record for fargo data 

Now we can check the contents of the file by going back to the top and 
typing all the lines « 

I > top I 
TOP; 

>type 10 j 
TOF: 

-COMMENT PRINT IS) RECORD FOR FARGO DATA 
*IDPRINT 

PRINT RUN(76020106) 

END 

EOF: 

When the Edit session has been completed there are two Edit commands for 
returning to LARSYS. They are FILE and QUIT. 

(aave the current file on diak) 

(aave the current file on diak with the new 
name 'name ') 

(don't aave the changea made during the 
current Edit aeaaion) 

To save our IDPRINT control card file, we can type 

>filel 

T=0. 50/4. 79 10:09:18 

and the file IDP CC will be stored on our computer ID with all the changes 
which have been made. This completes the Edit session and returns us to 
the LARSYS Environiiient. If we wanted to make further changes to this same 
file in the future the EDIT command should be used Instead of the GET 
command. The format of this command is: 

EDIT namel name! 

> edit idp cej 

(Iasue~^ty Edit commands to make changes desired) 

I > file 1 

1=0.10/0.4511:06:40 


FILE 

FILE ’name* 
QUIT 




t:<!> on <1 iak Fllna ; All filoa which you acoro oii your prlvnto disk have 
two namea which identify the file to the computoc. (In ttie above exanple 
the file Waa IDP CC). You must ramanbor this name for later commanda. It 
ia generally easier to remerabat the namea if you establish a naming pattern 
(such as always making the second name of a control card file CC or DECK, 
and waking the first namo an abbr aviation of the analysis area location or 
processor name). The names may consist of up to 8 alphanumeric charactora. 
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A QUICK REFERENCE TO EDIT COMMANDS 


namel nanie2 
^ottpm 

jChange /3tringl/strlng2/ 


DEL ete n 


£etflle namel name2 

I^nput new-line 
IJext n 

Replace new-line 

TOP 

Type n 
Up n 

FILE 

QUIT 


(move to the taot line of the file) 

(change 'atvingl ' to ^atvingZ* in thie line, 
where a atving is a aequenae of oharaatera* ) 

(delete tinea from the file, aborting 
with the current line. If *n' ia omitted, 
the current line ia deleted.) 

(inaert the file 'namel name 2' after the 
current line) 

(inaert line 'new-^line' after the current line) 

(move down 'n' tinea in the file. If 'n' ia 
omitted, move to the next tine. ) 

(replace the current line with 'new-line') 

(move to the top of the file) 

(type 'n' tinea, atarting with the current 
tine. If 'n' ia omitted the current line ia 
typed.) 

(move up 'n' linea in the file. If 'n' ia 
omitted, move up 1 tine. ) 

(atore the current file, with all changea made, 
on the private diak and return to LARSIS) 

(atop editting the current file without atoring 
changea which have been made) 


*r 


Note; Once you are familiar with the Edit commands, it is usually 
faster to use the abbreviations for the Commands. These are indicated 
above by the letters which are capitalized and underlined . Hence, the 
abbreviation for 'delete' is 'del* and the abbreviation for 'next' is 


'n' 
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CCINPUT 


RUN 


EXECUTE ^rHE LARSYS JOB 

To run a LARSYS Job, the control cards must be passed to the computer by 
reading them Into a card reader or by telling the computer whi^lh disk 
file contains the needed control cards, using the CCINPUT command. The 
format of the CCINPUT command is 

CCINPUT namel namcZ 

r>cc input idp ccl 
T-0.11/0.60 10:09;32 

You must know both names of your control card file, in this case IDP CC. 
In case you have forgotten the uame(s) of your control card file(s) , you 
may get a list of file names with the LISTFILE command. 


>liauflle * CC 


This indicates you want to list all files on your private disk with a 
second name of "cc". If you haVe forgotten the contents of a file, use 
the TYPE command, supplying the two names of the file. 

>type idp cc 


Hera, the contenta of the file IDP CC will be typed. 

Next type? 

^run I 

EXECUTION BEGINS . . . 

10065 IDPRINT function HAS BEEN REQUESTED. (RUNSUP) 

10114* IDPRINT function COMPLETED. (RUNSUP) 

10103 CPU TIME USED WAS 6.148 SECONDS. (LARSMN) 

I0004 END OF INPUT DECK ^ RUN COMPLETED (LARSMN) 

■10050 TOTAL CPU TIME FOR THIS RUN WAS 6.288 SECONDS. (LARSMN) 

PRT FILE 6458 TO RSCS COPY 01 NOHOLD 

T-2, 06/10.17 10:10!25 

Notice that LARSYS prints a series of informational messages indicating 
when the function begins processing and ends, A print file is created 
as normal output from a LARSYS processor and procedures for obtaining 
the printer output from your site can be found in the next section. 

You have now completed the general sequence for running a LARSYS job. 

The next step is to review your printer output and decide if you need 
to nm any more LARSYS Jobs. If so, go back to Section B, and create 
a new control card file. Then, using the name of this new file, enter 
the CCINPUT command and the RUN command. When you have executed the last 
LARSYS processor, proceed to Section E. 

Note on halting execution ; to terminate a job which is executing, press 
the BREAK key (computer types IGP') , and type '1 lsdv37Q' to rc-initiatc 
Che system. 
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D. OBTAIN PRINTER OUTPUT AT JACKSONVILLE 

The steps for receiving printer output from LARS are as follows: 

1. On the DECWRITER terminal type: 

m cp please start stregis 

(or call LARS computer room and ask them to check whether STREGIS 
is STARTED. Call: 317-74 9-2052 and ask for computer operator) 

2. Flip the LARS/DALLAS switch to position A 

Move to the IBM 3776 terminal for the following steps: 

3. Flip the reset switch on the IBM 3776 

4. Enter "local mode" (press "code" and "start job") 

5. To get 8 Lines Per Inch (LPI) , press "code" and "K" 

6. Press: "start job", "s", "3", "0", "EOM" 

(NPR should display 320) 

7. Put the SIGNON card In the reader and press START 

8. Receive print files. 

9. After all print files have been received, put the DRAIN card in the 
card reader, press START, and then flip the LARS/DALL^ switch 
back to B. 
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E. TERMINATE THE LARSVS SESSION 

QUIT When you have completed your work for the current terminal aeaaion, the 
QUIT command Is used to let the computer know you arc finished. 

I > quit I 

YOU TYPED QUIT. DO YOU NEED TO RETURN TO LARSYS TO SAVE ANY 
STATI STICS OR HISTOGRAM FILES? 
i >no i 

CONNECT- 00;16:38 VIRTCPU- 000:17.75 TOTCPU- 000:33.58 
LOGOFF AT 10: 05; 34 EST MONDAY 07/09/79 
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F. EXECUTE A LARSYS JOB. RECEIVING OUTPUT AT THE TYPEWRITER TERMINAL 


PRINT If for some reason you would like to receive the printer output from a 

LARSYS job at your typewriter terminal, then there Is a new LARSYS command 
to use called PRINT TYPEWRITER. Its format Is; 

PRINT TYPEWRITER llnewldth 


where "llnewldth" Is the number of characters which can be printed across 
your terminal i For the Decwrlter terminal, use 120. This command must be 
entered shortly before the RUN command. For example. If a control card 
file called JAXPRI CC had been created, the following command sequence 
would execute the job and return the output for printing on the Oecwrlter^ 


I >prlnt typewriter 120 
T-0.09/0.27 10;17;4T '^ 
| >cclnput jaxprl cc I 
^T«Q.li /Q.20 10; 19; 22 
|>run i 

EXECUTION BEGINS. . . 


10102 COMMENT - CLASSIFICATION RESULTS FROM RUN 76020106 

10113 PRINTRESULTS FUNCTION REQUESTED (PRISUP) 

10071 PRINTRESULTS FUNCTION COMPLETED (PRISUP) 

10103 CPU TIME USED WAS 19.651 SECONDS. (LARSMN) 


10004 END OF INPUT DECK - RUN COMPLETED (LARSMN) 

10050 TOTAL CPU TIME FOR THIS RUN WAS 19.725 SECONDS, (LARSMN) 
TAPE 181 DETACHED 
T^13.47/21.90 10:23:03 


OUTPUT 


After the job completes execution, the print file Is stored on a temporary 
disk file while you decide whether to print It out or run another LARSYS 
job, If you are ready to print the output, use the OUTPUT START command: 


>output start 
EXECUTION beg: 


;ns 


• • * 


(printer output ia typed) 


Warning: Do not try to print large outputs (such as all 4 channels In 

PICTUREPRINT) on the typewriter terminal, as It could take 
hours to print. 


PRINT To shift the output from the typewriter to the printer, then use the command 
PRINT 'location' 

to specify where the output should go. 

>prlnt streglsj 
T»0.09/0.27 10:35!01 ^ 

>cclnpu t newprlnt cc I 
T=0. 12 /0.30 10:37:23 
I >run I 

EXECUTION BEGINS... 


Note: The print location stays In effect for all jobs executed, until It Is 

changed by another PRINT command. 



G, SAVE STATISTICS FILES 


One important data file which LARSYS creates and later uses as Input to 
other processors Is called the LARSYS Statistics Flic. When you execute 
a LARSYS processor which creates a Statistics File* It Is important to 
save It on your computer ID's private dlstc storage after the job has 
finished executing. TO do this, use |;he STATDECK command: 

>statdeck save "name" 


You should supply a name for the Statistics Flic which la meaningful to 
you. If you forget what names you have already assigned, use the conunand: 


>statdeck status 


to get a listing of all of your saved Statistics Files. Later* when you 
want to Ovecute a LMSYS processor which require,!?! the input of a Stat- 
istics File, use the command: 

|>3tatdeck use "name"| 

before typing the RUM command. Examples of these commands may be seen 
in the next section . 
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Section II 


An Example I^SYS Analysle Sequence 


Before beginning an analysis of remotely sensed data, you should be 
familiar with the names and general functions of the LARSYS processors, 
have a computer ID and password, know what data you will be analyzing, 
and collect the "ground truth" (any information you can get on the ground 
cover for parts of your analysis area, such as maps, photos, statistical 
reports, etc.) you will use. The digital data used by I.ARSYS is identi- 
fied to the computer by a run number, which you should he informed of when 
the data is entered into the LARS Data Library. For the examples on the 
following pages the run number assigned to the data was 76020204. This 
data is over an area south-east of Columbus, Georgia. 

The typical analysis sequence has been Illustrated below. 
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OBTAIN A GRAYSGAI'E MAP OF THE DATA 
PICTUREPRINT 

The first step in the IJvRSYS Analysis sequence la Co get a pictorial 
representation of the data to check data quality and geographically 
orient yourself in the data. The PICTUREPRINT function in LARSYS reads 
data from the LARSYS Multlspcctral Image Storage tape and produces alpha- 
numeric pictorial printouts of the data for each channel that is specified. 
In this example maps of channels 2 and 4 (one visible and one Infrared 
channel) will be printed, (Noter It is not a good idea to receive the 
output from PICTUREPRINT at the typewriter terminal unless you are look- 
ing at one channel of a small area.) 

You should now turn to the control card reference page for PICTUREPRINT 
and write down the control cards you will need to use, checking the example 
which follows if necessary. 


VM/370 ONLINE 
! 


[ 


>1 stregis 




RD: 


bud _gQodrick 


LOGMSG - 08; 01: 17 EST TUESDAY 07/10/79 
* YOUR OPERATOR THIS MORNING IS CINDY.... 
LOGON AT 08 : 44: 35 EST TUESDAY 07/10/79 


>1 lsdv370 


DEVELOPMENTAL LARSYS READY; 

SYSTEM IS BEING INITIALIZED.... 


(Logon pvooedwe) 


. . . LARSYS IS READY FOR YOUR FIRST COMMAND 
T-0.42/4. 17 08:47:29 
I >get plcl 

'the FILE — PIC GC — IS READY TO BE EDITTED. 

IT'S CONTENTS ARE: 

-RUNTABLE 
DATA 

RUN(XX) , TAPE(YY) , FILE(ZZ) 

END 

-COMMENT GRAYSCALE MAP OF RUN XX 
★PICTUREPRINT 

DISPLAY RUN(XX) , LINES(A,B,C), COL(I,J,K) 

CHANNELS 2,4 

BLOCK RUN(XX), LINES(A,B,C) , COL(l,J,K) 

END 

EDIT: 

>next I 
-RUNTABLE 
^delete 4 
>type 

^ -COMMENT GRAYSCALE MAP O F RUN XX 

I .change /xx/76020204/ ^ <=- — — (tlote: iha * aaursei} thin 

^COMMENT GRAYSCALE MAP OF RUN 76020204 tjha.ngO SO be made in 

evfsr‘>j line) 


( Create the control 
card file) 
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OWGINAt PAGE 




1 V 


DISPLAY RUN(76020204) , LINES(A,B,C) , COL(I.J.K) 

BLOCK RUN(76020204), LINES(A,B,C) , COL(I,J,K) 

EOF; 

I >top 

*'TOP; *• 

I >nf»ct I 

,~c 6 Hwent grayscale map of run 74020204 . 

|>cimnge /4/4 columtuB, georgla teat slte/l 

-COMMENT GRAYSCALE MAP OF RUN 76020204 COLUMBUS. GEORGIA TEST SITE 

( >next 2 I 

DISPLAY RUN(76Q20204) . LIN ES(A.B.C) . COL(T,J,K) 

I >change /a.b.c/60.120^1 *1 

DISPLAY RUN(76020204)i LINES (60, 120, 1) , COL(I,J,K) 

BLOCK RUN(76020204) , LINES (60, 120,1), COL(I,J,K) 

EOF; 

. end 
| >up 3 


DISPLAY RON^ 76020204). L INES (60. 120.1) . COL(l,J,K) 

/1.1.k/335.475. Vl* l 

DISPLAY RUN (76020204), LlNES(60,120,l) , C0L(335,475,I) 

BLOCK RUN(76020204) , LINES(60, 120,1) , COL(335,475,l) 

|>topl 

TOFi 

l>type 99T 
TOF: 

>-COMMENT GRAYSCALE MAP OF RUN 76020204 COLUMBUS, GEORGIA TEST SITE 
*PICTOREPRINT 

DISPLAY RUN(76020204), L1NES(60, 120,1), COL(335,475,l) 

CHANNELS 2,4 

BLOCK RUN(76020204), LINES(60, 120,1), COL(335,475,l) 

END 

jsaEi,.., 

I >f lie 


T-0.66/8.51 09;08;22 

r>cc Input pic cc 
T«0. 1 2 / 6.61 09!09;52 
>ruin I 

EXECUTION BEGINS... i 


(Execute the MRS^S 
PICTVREPRim function) 


10102 COMMENT - GRAYSCALE MAP OF RUN 76020204 COLUMBUS, GEORGIA TEST 

SITE (LARSMN) 

10092 PICTUREPRINT FUNGTION R^^ (PICSUP) 

10237 ALL CONTROL CARDS FOR PICTUREPRINT HAVE BEEN READ (PICRDR) 
TAPE 182 ATTACHED 

10002 TAPE 4523 HAS BEEN REQUESTED ON UNIT 182 (TAPMOUNT) 

10003 TAPE READY... EXECUTION CONTINUING (TAPMOUNT) 

10036 DESIRED RUN FOUND ... 76020204 (GADRUN) 

10093 PICTUREPRINT FUNCTION COMPLETED (PICSUP) 

10103 CPU TIME USED WAS 36.012 SECONDS. (LARSMN) 

10004 END OF INPUT DECK - RUN COMPLETED (LARSMN) 

10050 TOTAL CPU TIME FOR THIS RUN WAS 36.197 SECONDS . 

PRT FILE 6418 TO RSGS COPY 01 NOHOLD 

TAPE 182 DETACHED 
T«ll. 74/41. 47 09:21 lie ‘‘ 


(LARSMN) 

■■ 
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B. DEVELOP TRAINING CUSS STATISTICS 

This phase is the heart of the analysis process, and is a series of 
several ntepa, which nay be re-iterated as needed. A general Rcheme 
of the order the proceasora may be used ia Illustrated below. 





CLUSTER 1 




l( MERGEST/ 

4TISTICSI 

5s 

Z 

... SEPARABILITY [ 


[cluster! 


Bl. CLUSTER - The cluster function implements an unsupervised classifi- 
cation (clustering) algorithm which groups data points Into a user- 
specified number of clusters. The processor creates a LARSYS Statistics 
File of means and covariances which is needed as input to the classlf 1- 
csticR processor end other LARSYS processors which uae statisclcs Infor- 
mation. The Statistics File must be saved on the user's private disk 
after the CLUSTER job has executed with the command 'STATDECK SAVE name', 
where 'name' is assigned by the user, typically, the 'name' is chosen 
to be meaningful to the user, such as a locatiun name. NOTE: The name 

must consist of only letters and numerals - no special characters are 
allowed. 


Before setting up the control card file you need to select several training 
areas in the data containing points that represent all the cover types. Use 
your grayscale map from PICTUREPRINT to help you do this. Note the starting 
and ending lines and columns for each area. You will now execute a separate 
CLUSTER job on each training area. 

Turn to the CLUSTER control card reference page and try to set up the 
first file you should use. The user-specified number of classes 'YY' ia 
entered on the OPTIONS MAXCLAS(YY) card. In this example, 12 classes are 
requested for an area from line 50 to line 94 and column 420 to column 476 
of the Columbus data. 

l>get clul (Create ike control 

THE FILE — aU CG -- IS READY TO BE EDITTED. card f He for ^CLUSTER) 
IT'S CONTENTS ARE; 


-RUNTABLE v 

DATA 

RUN(XX), TAPE<YY), FlLE(ZZ) ^ 
END 

-COMMENT CLUSTER ON RUN XX 
*CLUSTER 

OPTIONS MAXCLAS(YY), CONV(97.5) 
PUNCH STATS 
CHANNELS 1,2, 3, 4 


(These linea are only 
^ needed if the data is 
7 / copied to a user's tape.) 
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DATA 

RUN(XX), LINE(A,B,C), COL(I,J,K) 
END 


>next 
-feUNlABLE 
>delete A 
>type 


-COMMENT CLUSTER ON RUN XX 
CHANGE /XX/76020204/* 

-COMMENT aUSTER ON RUN 76020204 
RUN(76020204), LINE(A,B,C), C0L(I,J,K) 

-lOf; , , 

I >ncxt I 

-COMMENT CLUSTER ON RUN 76020204 
j>next 2 1 

'options MAXCLAS( YY) . C0NV(97.5) 
l>chan8e .yy»l2 | 

OPTIONS MAXCLA Sa2). CONV(97.5) 
>change .7^9.1 

OPTION S MAXCLAS(12) , GQNy(99«5) 
f >next| 

PUN CH STATS 


>d elate 
>next 


mt- 

[>next| 

RUN (7 6020204), LINE(A.B. C). COL(t»J,K) 
|>change .a,b,c.50.94«l.| 

RUN( 76020204. LINEfsCTi.l ). COL(l,J,K) 

pchange ,1,J ,k.420.276,r»l 

RUN ^7 6020204) . LINE ( 50. 94 . 1) , COL<420,476,1) 

EES 

TOP 

I > type 15 1 
' TOP: 

-COMMENT CLUSTER ON RUN 76020204 
^CLUSTER 

OPTIONS MAXCLAS(12), CONV(99.5) 

aiANNELS 1,2, 3, 4 

DATA 

RUN (7 6020204), HNE(50,94 ,1) , COL (420,476,1) 
END 

E Q F L - 

fllej 


T-O.61/3.00 10:36:25 


(These are the line and 
oolurnn ooordinatee for 
ihie training area) 
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|>cclnput clu cc| 

12CW 6 

l>nin| 

EXECUTION BEGINS.*. 


(Eoseouto the ^CLUSTER 
dob) 


10102 COMMENT « aUSTER ON RUN 76020204 

(LARSMN) 

10165 aUSTER FUNCTION REQUESTED. (aUSUP) 

10034 ALL CONTROL AND DATA CARDS NAVE BEEN READ. (aURDR) 

10002 TAPE 4523 HAS BEEN REQUESTED ON UNIT 182 (TAPMOUNT) 

TAPE 182 ATTACHED 

10003 TAPE READY... EXECUTION CONTINUING * (TAPMOUNT) 

10036 DESIRED RUN FOUND ... 76020204 (GADRUN) 

TAPE 182 DETACHED 

TIME IS 10s09j34 EST TUESDAY' 07/10/79 
CONNECT- 01:25:00 VIRTCPU- 000:19.08 TOTCPU- 001:17.41 
TIME IS 10:27:41 EST TUESDAY 07/10/79 
CONNECT-01;43;06 VIRTCPU- 003:22.61 TOTCPU- 004:37.44 
10171 FLAG- O NOMOD- 12 INTOT- 2565 INTV- 1 ITER- 16 TIME- 2 
05 SECS 

NCHAN- 4 CHAN- 1234 

10166 aUSTER FUNCTION COMPLETED. (CLUSUP) 

10103 CPU TIME USED WAS 220.473 SECONDS. (LARSMN) 

IQQQ4 END OP INPUT DECK - RUN COMPLETED (LARSMN) 

10050 TOTAL CPU TIME FOR THIS RUN WAS 221.120 SECONDS. (LARSMN) 
PRT FILE 6457 TO RSCS CVPY 01 NOHOLD 
T-194. 37/226. 23 10:32:38 

^statdeck save columbusi (Save the Statiatiae 

T-0. 38/2.40 10:39:^8 File) 


>statdeck status 

rosi37^ — — 


FILENAME 

FILETYPE 

FM 

COLUMBUS 

STATDECK 

A1 

COMBO 

STATDECK 

A1 

DEC76 

STATDECK 

A1 

DEC77 

STATDECK 

A1 

MOD 

STATDECK 

AL 

MODNULL 

STATDECK 

A1 

NONUL 

STATDECK 

A1 

PICAMOD 

STATDECK 

A1 

T-O.21/2. 

00 10:41:32 


FORMAT 

RECS 

BLKS 

F 

80 

57 

6 

F 

80 

119 

12 

F 

80 

70 

7 

F 

80 

76 

8 

F 

80 

74 

8 

F 

80 

65 

7 

F 

80 

65 

7 

F 

80 

103 

11 


(Diet all aaved 
StatiatioB Filea) 
DATE TIME 
7/10/79 10:29 
6/19/79 17:49 
•5/23/79 9:29 

4/20/79 9:33 

6IISI79 14:39 
6/19/79 13:58 
7/06/79 14:07 
5/10/79 11:03 


Nov repeat the above procedure for each training area you selected, 
by creating another CLUSTER control card file with the lines and 
columns for the next training area. Then issue the CCINPUT and RUN 
commands. After execution save the Statistics File with the STATDECK 
SAVE command, bfilng sure to use a different name. For this example 
we created two other control card files using the above file called 
CLU CC and the EDIT command to change the line and column numbers. 
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>edlt clu cc| 

EDIT; 

|> type 7 I 
TOFj 

-COMMENT CLUSTER ON RUN 76020204 
^CLUSTER 

OPTIONS MAXCLAS(12), CONV(99.5) 

CHANNELS 1,2, 3, 4 
DATA 

RUN> 76020204). LINE(50 . 94 ,1) , COL(42b, 476,1) 
l>change /50,94/79,113/j 

RUN (7 6020204) . LINE (7 9. 113 ,1) , COL(420, 476,1) 
>change /420,476/333, 364/1 

RUN( 76 020204) . LINE('i79.113 .1) ■ GOL(333, 364,1) 
>£ile I 

T“0.23/4.72 07;32:47 


>cc input clu cc 1 
't-O. 1 2/1.01 07; 33; 16 
>run I 

EXECUTION BEGINS. .. 
3rd CLUSTER job 


(yhen execution ia completed Use the 
atatdeok save oormandt using a diff- 
erent name than the fivet saved file) 


>edlt clu cc I 
EDIT; _ 

>type 7| 

TOF; 

-COMMENT CLUSTER ON RUN 76020204 
★CLUSTER 

OPTIONS MAXCLAS(12), CONV(99.5) 

CHANNELS 1,2, 3, 4 
DATA 

R0N.( 7 6020204) . LINF.(79 . 113.1) . COL(333 .364 .1) 

|>change /79.113/60 .9o7l 

RUN^76020204) . LINEr6d.90. 1) . COL(333, 364,1) 

>change /333. 364/420. 475/1 
WiZii020204) , LINE(60,90,1), C0L(420,475,1) 
pile 

T=0.26/1.03 15:48 :26 

i>ccinput clu ccl When execution is aompletedy use the 

T«0.08 /0.23 15:57:13 save command, using a name 

[ >run I different from the above two saved files) 

EXECUTION BEGINS . . .isT ■ 

j (If you are done for now, type QUIT. ) 

YOU TYPED QUIT. DO YOU NEED TO RETURN TO LARSYS TO SAVE ANY 
STAT ISTICS OR HISTOGRAM FILES? 

I >no 1 

CONNECT^ 02;00:04 VIRTCPU- 003:30.29 T0TCPU= 004; 59.94 

LOGOFF AT 1%44 : 41 EST TUE^ 


VM/370 ONLINE 




Obtain the print files for these CLUSTER jobs ana compare the cluster 
maps in the output to any ground truth (maps or photos) you have. 

Clve a name tP as many of the cluster classes as possible in each of 
the three areas. Don't worry if you can't name all the classes, since 
we have several other programs to aid us. 

Remember that you created three separate Statistics Files. It is very 
probable that there arc statistical values in each Statistics File 
that represent the same cover type on the ground. To combine these 
classes and allow us to better compare the other classes, it is nec- 
essary to merge the Statistics Files. 
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B2 . BMERGESTATISTICS - The mergestatistlcs processor provides the capability 
of cotnblhing several LARSYS Statistics Files or decks and edlttlng the 
resulting new file. Classes from the input Statistics decks may be com- 
bined (pooled), deleted and renamed. This processor is frequently used in 
conjunction with the SEPARABILITY processor (discussed next) to identify 
redundant or unnecessary classes, and then combine or delete them as 
required. The 'Separabillty-Mergestatistics’ processor combination may 
be repeated if the analyst feels class redundancy Justifies its use. 


The Version of this program we use is called BMERGESTATISTIGS , so we 
create our control card file and execute the job as follows: 


>logon stregls I (Logon) 

enter passw ord! 

>xxxxxxxx 1 

enter name ;|>bud goodrlcki 

LOGMSG - 13:00:06 EST THURSDAY 07/19/79 

* YOUR OPERATOR THIS AFTERNOON IS CINDY.... 

* NEXT SCHEDULED SHUTDOWN IS SATURDAY JULY 21 AT 17:00... 
LOGON AT 13 :00:58 EST THURSDAY 07/19/79 

>i lsdv370| 

DEVELOPMENTAL LARSYS READY} 

SYSTEM IS BEING INITIALIZED.... 


. . . LARSYS IS READY FOR YOUR FIRST COMMAND 
T»Q.35/A.01 11;A7:41 
>get bme cc | 

THE FILE — BME CC — IS READY TO BE EDITTED. 
IT'S CONTENTS ARE: 


(If you have forgotten the names 
of your statistiaa files use the 
STATDECK STATUS oormand before 
the GET aomand. ) 


*BMERGE (Create the control card file) 

OPTIONS NOFIELD, COSPEC 
CLASSES ENTIRE (1,2) 

SCALE SPCINT(l) 

DISK READ 

DATA (USE GETFILF. COMMAND TO INSERT YOUR STATDECK AFTER THIS CARD) 

DATA ( USE GETFILE COMMAND TO INSERT YOUR STATDECK AFTER THIS CARD) 

END 


RUT.'n. , 

}>next 3 I 


CLASSES ENTIRE (1 .2Y 


>change /2/2,3/ 


CLASSE S ENTIRE(1,2,3) 


>next 


SCALE SPCINT(I) 
>next 1 


DISK READ 


>delete 

>type 


DATA (USE GETFILE CONM AND TO INSERT YOUR STATDECK AFTER THIS 
I >getfile csg statdcckl. 

EOF REACHED 

EOS ***** LAST CARD OF STATISTICS DECK 


CARD) 

***** 
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I >next I 

' data (use GETFTT.R rO^ AWD TO INSERT YOUR STATDECK AFTER THIS CARD) 
|>getf life au49 atatdecin 


EOF REACHED 
EOS 




>input data 
>getflle Columbus statdec 


3 


LAST CARD OF STATISTICS DECK 


AAAAiiV 


LAST CARD PF STATISTICS DECK 




EOF REACHED 

EOS ***** 

END 

r>topi 

^£1 

(>type 8^ 

' t 6 f : ” 

ARMERGE 

OPTIONS NOFIELD, - COSPEC 
CLASSES ENTIRE (1,2, 3) 

SCALE SPciNT(l) 

DATA (USE GETFILE COSPIAND TO INSERT YOUR STATDECK AFTER THIS CARD) 
LARSYS VERSION 3 STATIS'fTCS FILE 0 

CLASS TPL7601 
|>£He 1 

;t.Q.54/7.48 11;5 9.»17 


i^c input bme cc[ 

't»«0. 54/7.48 11;59!41 


(Execute the EMERGE job) 


EXECUTION BEGINS... 

lOXXX MERGESTATISTICS FUNCTION REOUESTED 


(MERSUP) 


10034 ALL CONTROL AND DATA CARDS HAVE BEEN READ 
lOXXX STATISTICS BEING MERGED (MERSTT) 

10032 REDUCED STATISTICS COMPUTED. (REDSAV) 

10032 REDUCED STATISTICS COMPUTED (REDSAVV 

10032 REDUCED STATISTICS COMPUTED, (REDSAV) 

T0209 COINCIDENT BI-SPECTRAL PLOT PRINTED. (COSPEC) 

lOXXX MERGESTATISTICS FUNCTION COMPLETED (MERSUP) 

10103 CPU TIME USED WAS 16.155 SECONDS. (LARSMN) 

10004 END OF INPUT DECK - RUN COMPLETED (LARSMN) 
10050 TOTAL CPU TIME FOR THIS RUN WAS 16.400 SECONDS. 

PRT FILE 4952 TO RSCS COPY 01 NOHOLD 
T»9. 96/22.11 12t03;l4 


(MERSUP) 


(LARSMN) 


>statdeck save csg3deck| 

" 1 = 01 / 1. 96 12 : 15:01 





118 


OfijGJNAl PAGE IS 

OF POOR QUALITY 


B3. SEPARABILITY - The separability processor helps the user to decide how 
well the individual classes In a LARSYS Statistics File may be distinguished 
from one another, i.e. What is the "separability” between the classes. It 
is also used to select a subset of channels in a Statistics File which will 
produce an accurate classification. The first reason. Is why we will use the 
separability function now. We want to compare all of our cluster classes 
which have been combined into one Statistics File during the BMERGESTATISTICS 
Job. 

Now create your SEPARABILITY control card file. If you have forgotten the 
names of your Statistics Files, type ’statdeck status' before issuing the 
'get' command. 


>get sepi 

THE FILE — SEP CC — IS READY TO BE EDITTED. 
IT'S CONTENTS ARE; 


-COMMENT SEPARABILITY ON CLASSES FROM RUN XX 

★SEPARABILITY 

COMBINATIONS 4 

SYMBOLS A,B 

CARD READSTATS 

CHAilNELS 1,2, 3, 4 

data 

★ PUT STATISTICS DECK HERE IF A CARDS READSTATS CARD IS ABOVE * 
DON'T FORGET TO DELETE THESE TWO LINES. 

END 


^DIT; 


>next I 

-COMMENT SEPARABILITY ON 


>Ghange /XX/76020204/1 
-COMMENT SEPARABILITY ON 
>next 3 


SYMBOLS A.B 


>delete 6 


COMBINATIONS 4 


>input print dlv(l200)| 
>top 


TOF: 


>type 6 


TOF: 

-COMMENT 


CLASSES FROM RUN XX 
CLASSES FROM RUN 76020204 


(The 4 indicatea we want to uae atl 4 ohannela 
in computing otaaa aeparabilitiea) 

AClaaa pair aeparabilitiea are aaaigned a number 
-2000, the higher the number, the more aep- 
arable the otaaaea, Thia line oauaea a tc^le 
to be printed of claaaea with separability leaa 
than 1200 which are candidates for combining. ) 


★SEPARABILITY 
COMBINATIONS 4 
DIV (1200) 

MP— - 
>f lie 1 

T=0. 54/1.28 13:45:21 
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lOm SEPARABILITY FUNCTION REQUESTED (SEPSUP) 

10032 REDUCED STATISTICS COMPUTED. (REDSAV) 

10034 ALL CONTROL AND DATA CARDS HAVE BEEN READ (SEPINT) 

10022 DIVERGENCE CALCULATIONS COMPLETED— READY TO ORDER AND PRINT RESULTS 
1001 I SEPARABILITY FUNCTION COMPLETED (SEPSUP) 

10103 CPU TIME USED WAS 22.083 SECONDS. (LARSMJ?) 

y 

10004 END OF INPUT DECK - RUN COMPLETED (LARSMN) 

10050 TOTAL CPU TIME FOR THIS RUN WAS 22.339 SECONDS . (LARSMN) 

PRT FILE 4954 TO RSCS COPY 01 NOHOLD 
T-13.49/27.30 12;‘10!34 

y 

After obtaining the printer output from this SEPARABILITY job, turn to the 
table of suggested class groupings. Compare this with the names you assigned 
to the classes in the CLUSTER output. Based on how well the grouped classes 
agree with respect to coyer type, you should decide whether to combine or 
delete classes. 

Your next step is to create another BMERGESTATISTICS control card file with 
the class combinations indicated on the POOL card, and then re-run the 
SEPARABILITY processor, changing the DIV value to 1400. Do this as many 
times as is necessary. Don't forget to save the Statistics File after 
BMERGESTATISTICS is executed. 

After the 2nd BMERGESTATISTICS job has been executed, you may also choose 
to run the BIPLOT processor, as follows: 

■ . 



1 

I 


1 
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B4, biplot - The Blplot processor provides the user with a graphic pre- 
sentation of the reTeti'oriships of the classes in a statistics deck. 
Two-channel plots of means, ellipsoids of concentration, and classification 
space for training classes may be requested. The plots are used to examine 
the spatial relationship of training classes in two channel space. Any 
two channel combinations may be plotted. 


>get bip 
THfi FILE BIP CG 
IT'S CONTENTS ARE: 


IS READY TO BE EDITTED. 


-COMMENT BIPLOT OF CHANNELS X,Y 
*BIPL0T 

PLOT MEANS (X,Y) ,ELLIPSE(X,Y) ,CLASS(X,Y) 

SCALE ORIG(X,0.0), 0RIG(Y,0.O), UNIT(X,0.8), UNIT(Y,0.6) 
END 


EDIT; 


l>type 5 
TOF: 
*BIPL0T 



(%88ue Edit oomarids here to create a file 
which looke like this:) 



PLOT ^lEA^^S<3^2) iCLASS(3j2) 

SCALE 0RIG(3 ,0.0), ORIG (2 , 0 , 0) , UNIT (3 , 0. 5) , UNIT (2,0.5) 


END 

I >f ile ) 

■T«0.09/1.17 17; 05; 12 
>statdeck use csg 
T-O. ^ 2/0.61 17!Q7:49 
|>run 


EXECUTION BEGINS, 


(our final Statistics File is named 'csg') 


10000 BIPLOT FUNCTION SELECTED (BIPSUP) 

10000 READ STATISTICS COMPLETED (BIPRDR) 

10000 ALL CONTROL AND DATA CARDS HAVE BEEN READ (BIPSUP) 
10000 DOING CLASSIFY PLOT OF 2 VS 3 (BiPLTR) 

lOOOG DOING MEANS PLOT OF 2 VS 3 (BIPLTR) 

lOOOO BIPLOT FUNCTION COMPLETED (BIPSUP) 

10103 CPU TIME USED WAS 12.108 SECONDS. (LARSMN) 

10004 END OF INPUT DECK - RUN COMPLETED (LARSMN) 


10050 TOTAL CPU TIME FOR THIS RUN WAS 12.228 SECONDS. (LARSMN) 
PRT FILE 5943 TO RSCS COPY 01 NOHOLD 
T“ll. 22/13.85 17;08;56 
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CLASSIFY THE DATA 


Having completed the necessaty iteration of steps in part to develop 
your training class statistics, you are ready to classify all the data 
points in your analysis area. 


CLASSIFYPOIHTS - The classifypolnts processor uses the maximum likelihood 
classification rule which classifies multlspectral data on a polnt-by- 
polnt basis. The processor assigns each data point to a class in the 
training set (LARSYS Statistics Files) for which the data values give 
the maximum likelihood for statistically correct classification. The 
classification file is written onto tape or disk. 


Now create a control card file for CLASSIFYPOINTS and execute the job. 


>get cla I 

'rtlE FILEI — CLA CC — IS READY TO BE EDITTED. 
IT'S CONTENTS ARE: 


-RUNTABLE 

DATA 

RUN(XX), TAPE(YY), FILE(ZZ) 

END 

-COMMENT PERPOINT CLASSIFICATION OF RUN XX 

*CLASSIFYPOINTS 

RESULTS TAPE(X),FILE(Y) 

CLASSES MM(P1/C1,C2/) <— (The 'atasses ' card is not needed if 

CHANNELS 1, 2, 3, A you have already combined your olas'' 

DATA es in the EMERGE dobs) 

RUN(XX), LINE(A,B,C), COL(l,J,K) 

END 


EDIT; 

*CLASSIFYPOINTS 
RESULTS DISK 
CHANNELS I, 2, 3, A 
DATA 

RUN(7602020A) , LINE (lAO, 180,1) ,COL(60,200,1) 


(Issue Edit commands here to get a 
file such as the one typed below) 


(If you have a larger area^ you will 
need to put it on tape instead of disk) 


...ENC 

>filc 1 

T=0. 15/0. A9 IA:51 ;35 
I >cclnput cla cc j 
T=0.0q/0.18 lA; 52: 03 
|>stacdeck use csg| 
T»Q.0 9/0.23 1A;56; 39 
I >r un I 

EXECUTION BEGINS . . . 


At this point the data has been classified and you can proceed to display the 
data. 



DISPLAY THE RESULTS 


PRINTRESULTS - The, Printresults processor produces printed outputs des- 
cribing the classification results, in the form of map images, tabular 
summaries, or both. The user can assign various symbols to the classes 
for the maps, and produce several types of tables. All output products 
are optional and various combinations of products may be produced, with 
multiple copies produced If requested. 

If you choose to produce a map, then you must first select symbols to 
assign to each class, ('(any special symbols may be used, such as 'blank', 

"• /> +> “» “» etc. in addition to letters and numbers. 

I >get prl I 

THE FILE — PRI GC — IS READY TO BE EDITTED. 

IT'S CONTENTS ARE: 

-COMblENT CLASSIFICATION RESULTS FROM RUN XX 
^PRINTRESULTS 

RESULTS TAPE(TT), FILE(FF) < — (specify here wheve the clasaifioation was 
PRINT TEST(P) written) 

SYMBOLS - ,+, . ^ ( aymbola are required for a map) 

GROUP GG(G1/P1,P2/) 

DATA (data cards are needed if tables are requeeted) 

TEST 

RUN(XX), LINES(A,B,C), COL(I,J,K) 

END 

(laaue Edit commando here to create your file. 
The following file oust requeata map output.) 

^PRINTRESULTS • 

RESULTS DISK 

SYMBOLS ,.,.,/,/,/,/,X,X,X,H,H,H,W 

END 
> file I 

Execute the job using the CCINPUT and RUN commands. Obtain your printer 
output and look for problem areas In the classification. It may be nec- 
essary to repeat several steps from part B to redefine the training class 
statistics. If no problems are apparent, Chen you have completed Che 
analysis Sequence and may produce Various other maps or Cables, grouping 
similar class types as desired. 
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QUALITY 


Instructions to Convert Linear ParamsterS to 4-Parameter Non-Conformal 
Transformation for use by the LARS Imago Registration System, 

(This algorithm is for use with Landsat-EDIPS formatted geometrically 
corrected tapes). 

1. Set up the distortion matrix M such that 


where 


h 


^2 



H » 


T" 

1.0 

0.0 


0.0 

»!»■ 

1.0 

‘ 

cos 0. 

sin 0 

-sin 0 

cos •© 


for pixel scale (assumes 57m pixel) 


for rotation^ where Q is the rotation 
reqiAired to a north-south orientation. 




1.0 0.0 

1.0 0.0 


. -1 / cos ( 80.985 
V cos (|) 

where (|) is run center latitude 
for skew- (already corrected by EDIPS) 


li. 


0.8 

0.0 


0.0 

1.0 


for a line printer aspect of 8 lines 
per inch, 10 columns per inch 




1.3368421. O.O"] 
0.0 1. 3368421 i 


for scale correction to 1:24000 from a 
scale of 1:17952.7 
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M » 


1.0694737 cos © 1.3368421 sin © 

-1.0694737 sin © 1.3368421 cos © 


This distortion matrix is sot up for the trana formation 
y » M X 

where X is the original coordinates and 
Y is the new coordinate matrix. 


2. To put this into a form suitable for the registration equations 

Y » X + A 

we mus t use the form 

Y =« A X 

Expanding; Y * A X; - >1 ^ 

'l ■ ^1*1 + “12*2 = “l + •>«2 . c + 

*2 ' “ 21*1 * “ 22*2 ■ ^*1 *•^’’ 2 * ^*-2 
lot o .. f » 0, 

“ll*l * “12*2 ” I" + + •>«2 

“21*1 * “22*2 = <5*1 + (6 -HlXj 


or, 


“ii = “ + 1 
“12 

“ 21 “^ 

Oj2 = e + 1 


or. 


A *= 


a + 1 b 
d e + 1 



To convert A in terms of ovorltty lino (CUO) and column (cjd) 
coefficients of the image registration system, it is only 
necessary to obsorvo 

a - CTO3 » 1.0694737 cos 0 - 1 
b - CJD2 " 1,3368421 sin 
d « CID3 —1.0694737 sin 
e n CLD2 »- 1.3368421 cos 0-1 
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DATE} 9/25/79 


REFORMATTER} Smith 


WP p» 556-PR 
MACTw 796 


INPUT 


CPU- 


RUN A 77010200 LINES 1,600 COLS 73,435 CHAN - 

RUN B 77010201 LINES 1,750 COLS 500, llOOCHAN All 

BUFFER USED} 


OUTPU T 

RUN 77010202 TAPE 2668 FILE 2 

INTERPOLATION} NN 

DATA TRANSFORJIATION INFORMATION 


TRANSFORMATION} 

LINE RMS } 0.70806 

COL RMS } 1.03212 

N j . 14 

DISTRIBUTION R} 0.99 

CORRELATION NA 

RATE OF ACCEPTANCE ACCEPT REJEC T RATE 

AVERAGE RHO } 

AVERAGE EUCLIDEAN ERROR ; 


TRANSFORMATION COEFFICIENTS; 



LINE COEF. 1; 

3a,494452 


COL COEF. 1; 

543.055448 

2} 

0.015229 


2; 

-0.005780 

3: 

0.005092 


3: 

-0.013307 

4: 



4; 


5: 



5; 


6: 



6: 


THE FOLLOWING 

FIRST ORDER 

DISTORTIONS 

WERE CORRECTED; 



SCALE 

X: 1.0152 

Y; 1 

.0000 


ROTATION 

0.326 

(DEGREES) 



SKEW: 

0.0299 

(DEGREES) 



FORWARD 


/^ACKWA^ 


ORDER 


Registered to USGS Quad Maps 


0R161NAU PAGE 13 
OF POOR QUAUTY 
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IMAGE REGISTRATT.ON PERFORMANCE REPORT 

* 583**IR 

DATE* lO/Uy?*) REFORMATTERi Smith 

hac t* 

CPU-.^ 

INPUT 

RON A 770102O2 LINES 1,600 COLS 1,428 CHAN 1-4 

RUN B 79000201 , LINES 1,739 COLS 1,504 CHAN 1-4 

BUFFER USED: 7246 bytes 

i: 

OUTPUT 

RUN 79000202 TAPE 2848 FILE 1 

INTERPOLATION: NN 

DATA TRANSFORMATION INFORMATION 

TRANSFORMATION: FORWARD (^CKWARD^ ORDE R 2 

T.TME RMS ’ : 0,099 
COL RMS : 0.283 

N : 185 

DISTRIBUTION R: NA distribution appears excellent 

CORRELATION 

RATE OP ACCEPTANCE ACCEPT 185 REJECT 85 RATE_ 


66.39532730 
0.00264544 
* 0.00066831 
-0.00000293 
-0.00000105 
0.00000014 

1.0006683 

SKEW: 0.075 (DEGREES) 


AVERAGE RHO 

AVERAGE EUCLIDEAN ERROR 
TRANSFORMATION COEFFICIENTS 
LINE COEF, 1: 129.20298180 
-0.00008529 


0.69 

0,67 


2: 
3 : 
4; 
S: 
6 ; • 


-0.00133339 
-0.00000039 
0.00000173 
0.00000115 

THE FOLLOWING FIRST ORDER DISTORTIONS WERE CORRECTED 
SCALE X; 0.9999183 Y: 

ROTATION -0.1515851 (DEGREES) 


COL COEF. 1; 

2 : 

3: 

4 : 

5: 

6 : 
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IMAGE REGISTRATION PBI^ORMANCE REPORT OF POOR QUALITY 


DATE} 10/5/79 


REFORMATTER: Smith 


INPUT 


OUTPUT 


W P» 572-GC 
MAC T* 796 
CPU- 


RUN A 79000300 LINES 762, ISOOCOLS 1200*1698 CTAN none 

RUN D 79000200 LINES 600, 1700COLS 1000,2150 CHAN 1-4 

buffer USED: 1,500,000 


RUN 79000201 
INTERPOLATION; 


TAPE 2836 PILE 1 

DATA TRANSFORMATION INFORMATION 


TRANSFORMATION : 
LINE RMS : 
COL RMS S 
N ; 
DISTRIBUTION R; 


FORWARD 


( T^ackwa^ order 


NA; systematic distortions corrected for rotation, 
scale, aspect only 


CORRELATION 


NA 


RATE OF ACCEPTANCE 


ACCEPT 


REJECT 


RATE 


AVERAGE RHO 

AVERAGE EUCLIDEAN ERROR 
TRANSFORMATION COEFFICIENTS 
LINE COEF. 1: 0.0 


2 : 
3; 
4; 
5 ; 
6 : 


0.314711 

-0.1937948 


NA 


COL COEF. 1: 
2 : 
3: 
4: 
5: 
6 : 


0.0 

0.2422435 
0 .0517688 


THE FOLLOWING FIRST ORDER DISpllIgNS^ WERE CORRECTED:^ 0694737 
SCALE X; li2400C lP Y; I : 24000' LP 

ROTATION 10°. 44 (DEGREES) 

SKEW; 0°.0 (DEGREES) 
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ORiGiNAL PAGE tS 
OF POOR QUALITY 
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ORIGINAL PAGE IS 
OF POOR QUAUTY 

3.4 Ratio Evaluation 

During Che course of the FRIS Project LARS Project personnel became 
aware of forest managements need to quantitatively relate Landsat and 
forest inventory data. One approach that was especially noteworthy in- 
volved the application of regression analysis to Landsat MSS reflectance 
values. The predicted variable was the age of pine plantations, which is 
an indirect measure of crown closure. Crown closure is a measure of stand 
stocking which is an inventory measure. 

More precisely the ratio of the infrared to visible band responses 
are assumed to be affected by stand occupancy, which is reflected in 
crown closure. As stands mature, Individual tree crowns occupy a greater 
proportion of the site (figure 3.4.1). The increasing crown closure 
affects the ratio, which in preliminary tests corresponds well to a 
measure of age. 

3.4.1 Knabb and Picayune Ratio Results 

The ratio of IR channels to visible channels from December 1977 
Landsat data for the Knabb and Picayune tracts were used to predict the 
age of selected pine fields. The exact ratio used, the method of picking 
pine fields, the analysis used to predict the fields ■ ages and the re- 
sults of these predictions are outlined below. 

The exact data ratio generated was as follows; 

ratio = 40.0CC3 + G4)/(C1 + C2 + 0.1) 
where 

Cl « channel 1 
C2 - channel 2 
* C3 = channel 3 

C4 = channel 4 


The multiplier 40.0 and the constant 0.1 were needed to enhance the range 
of and information in the data, and to prevent a divisor of zero. 

The Knabb Tract was first categorized into pine and non-pine classes. 
From this classification fourteen fields of seemingly homogeneous pine 
were selected and the average ratio for each field was determined. Due 
to the proximity of this tract to the Fargo test site and their similar 
physiography, a regresaion equation developed for Fargo was used to 
predict the ages of the selected Knabb fields. Four of the Knabb fields 
were dropped from further analysis. Two of these discarded fields were 
accidently picked outside the Knabb boundaries and the other two dropped 
fields were inaccessible for checklnji; ground truth. Of the ten pine 
fields left, a ground inspection of 4he area established that (1) all ten 
fields were pine, and (2) nine of the ten fields had ages within the ninety 
percent confidence Interval for each predicted age. Ages were derived by 
taking increment cores and counting growth rings of randomly selected 
dominant trees. 





KAS4 BATELLm: TO AID 
TIMBER XKDCCTHY 

tion DoiinjQUA 

or noKOA 

^ iKiiiXKOXWEor u:naaDrTATXT^ 

Mondav, April Z£, 1980 

m Mr. ruqUA. Mr, Speaker, I would 
Uke to call to the atumiol^i of toy col- 
leagues a recent release by NASA de- 
pleting a ca5c In cost staring between 
a Oovemment agency and private con- 
cern. This ts another example of the 
I benefits being derived by tiic technol- 

ogy being developed Ih our space pro- 
graxzu 

i An Eaxth resourcwi NASA aateUlte 

hiLS found a new uyej Gathering dau 
^ to lmpro\»c management of Americana 

forest lands- The project reflect* a 
unique retoionahhp between the Gn«- 
enmuent agency and the private 
aceter, one In trhich the imxiatlng 
company U sharing the toui cost boa 
the technology developed uoU bo avaU- 
tblo to all enher Umber campcmca. 
The ntelhte la l^daat^. The ccinpi^ 
ny la the St, Regis Paper Ca 
StDce 1A77, St. Regis has been worU- 
Inir with NASA in a test procram to 
tec U Landsat dau couid imnro\*c the 
paper Industry's information base on 
fortfl lands. St, Regis wanu to use the 
data for planning timber harvests- 
leasing and buying new Umber Lands, 
iuad to ‘ monitor more than 920,000 
V hectarts— 2.3 million acres— across the 

I South, 

i The project has been so successful 

H that the St, Regis Southern Timber- 

I land Division, Jacksonville, Fix, re- 

;? ccntly authorised over 1300,000 of new 

I capital Investment for a forest ns 

‘ aource IniormaUoa system to us« 

^ Landsat dau to supplement conven- 

UonaUy acquiml daU In Its general 
operations, 

j;| ^ The entire forestry industry stands 

■ t to gain frera the venture because tcch- 

^ i noJogy developed by the St. Regis ex- 

II periment U in the public do mam and 

hi available to other ecmparucs. The 

f l company and NASA plan to conduct a 

j symposium In 1981 to demonstrate 

lindsat InterprctaUon methods to 
timber Industry managers. 

St Regis was the first pnvate com- 
pany to act as a user In NASA’s re- 
source obsen’ation appUcatlora test 
program. The project ctitabbsfaed a 
i unique rcUUonship between NASA 

and the private sector for 5U Regis inl- 
I Hated the project— rather than 

NASA— and the company is sharing in 
- i the total coat, 

/I BL Rcrii wiU use technique* devel- 

' V. oped in the project at lti Daiiaa com- 

\ putcr facility to process the data 


cotnlnt from Landsat which win com- 
plement the automated dau baia at 
Bt. Regis dlviiiorrsl remote sensing 
center An JncVpvonvlUc, This combined 
data will assist the company In esti- 
mating Umber volume and productlv- 
ftfi as well as changes la the condJ- 
riona of the forests. 

Landsat daU wUQ be used to deter- 
mine distrlbuUon of the major types 
of tree* on SL Regls-oumed tlmberJand 
In Texas, Florida, Ceorria, Aiabama, 
’Mississippi, and Louisiana and other 
land available through lease or pur- 
chase. 

The project ts being conducted by 
NABA's Jo hn s on Space Center, Kous- 
Xtax the Laboratory for Applications 
of Remote Seming at Purdue DcJver- 
atty in Lafa>^Ue, Ind 4 and the SL 
Regis Paper Ca It U scheduled to end 
in September of this year. 

Landsat-O orblt\ the glebe M times * 
day at an aldtudc of 900 kilometers— 
aej miles. Its electronic mulUrpectnU 
scjinner returns data which U proc- 
essed Into film aiad computer tape 
format This resource iniormaUon 
may be used to dukracterixe dUferent 
type* of terraixu aegtuUon, aoiijL 
ic&ka, and other ci rf jtrf> feauijnes.p 


